Diese Übersetzung ist unvollständig. Bitte helfen Sie, diesen Artikel aus dem Englischen zu übersetzen.

SpiderMonkey erstellen

Befolgen Sie diese Schritte um den aktuellsten SpiderMonkey Build zu erstellen.

Bevor Sie jedoch beginnen, stellen Sie sicher, dass sich die richtigen Build Werkzeuge auf Ihrem Computer befinden: Linux, Windows, Mac, others. Sollten Sie eine ältere Version als 28 erstellen wollen, benötigen Sie zusätzlich NSPR.

Selbstverständlich benötigen Sie auch den SpiderMonkey Quellcode.

Non-developer (optimierter) Build

Befolgen Sie diese Schritte wenn Sie SpiderMonkey einfach nur installieren oder es als Bibliothek nutzen wollen. (Wenn Sie SpiderMonkey an sich verbessern wollen, sollten Sie zusätzlich einen Developer/Debug-Build wie unten beschrieben erstellen.)

cd js/src
autoconf-2.13

# This name should end with "_OPT.OBJ" to make the version control system ignore it.
mkdir build_OPT.OBJ
cd build_OPT.OBJ
../configure
# Use "mozmake" on Windows
make

Beachten Sie, dass autoconf version 2.13 benötigt wird. Keine ältere Version wird funktionieren. Das MozillaBuild Paket für Windows beeinhaltet autoconf 2.13.

Hinweis: Sollten Sie einen Mac nutzen und eine ähnliche Fehlermeldung wie folgendes erhalten:

"checking whether the C compiler (gcc-4.2  ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
"

Dann können Sie versuchen es so zu konfigurieren :

CC=clang CXX=clang++  ../configure

Dies erstellt eine ausfühbare Datei mit Namen js im Verzeichnis build-release/dist/bin. Sie können es mit dist/bin/js --help testen,  welches eine Hilfeseite anzeigt. An diesem Punkt sind Sie bereit die Shell auszuführen und zu testen.

Auf Mac, Linux, oder UNIX können Sie SpiderMonkey auf Ihrem System mit dem zusätzlichen Befehl make install installieren. Dies installiert die geteilte Bibliothek nach /usr/local/lib, die C-Header-Dateien nach /usr/local/include, und die ausführbare js  nach /usr/local/bin.

Developer (debug) Build

Um SpiderMonkey zu debuggen und zu verbessern ist es das Beste beide, einen Debug-Build  (für alltägliches debugging) und einen optimierten Build (zum Testen der Performance), in separaten Build Verzeichnissen zu haben. Daher sollten Sie zusätzlich zu den oben genannten Schritten auch einen Debug-Build mit den folgenden Schritten erstellen:

cd js/src
autoconf-2.13

# This name should end with "_DBG.OBJ" to make the version control system ignore it.
mkdir build_DBG.OBJ
cd build_DBG.OBJ
../configure --enable-debug --disable-optimize
# Use "mozmake" on Windows
make

Sie können auch Debug-Builds von SpiderMonkey mit der Option JS_GC_ZEAL  erstellen, die SpiderMonkey eine neue integrierte Funktion hinzufügt, mit der Sie eine eifrige Garbage Collection konfigurieren können. Dies ist nützlich um Speicherlecks und andere speicherbezogene Probleme zu beheben. Siehe JS_SetGCZeal() für weitere Details.

Für eine Liste anderer verfügbarer Build-Optionen geben Sie Folgendes ein (vorausgesetzt, das aktuelle Arbeitsverzeichnis ist eines der oben erstellten Build-Verzeichnisse):

../configure --help

Windows Builds

Seit Version 28, sind threadsafe Builds Standard und sollten auf allen POSIX-Plattformen sofort einsatzbereit sein. Daher sollten die folgenden Anweisungen nur relevant sein, wenn Sie unter Windows arbeiten oder eine ältere Version von SpiderMonkey kompilieren.

Die MozillaBuild-Batch-Datei, die Sie zum Öffnen Ihrer Shell verwendet haben (z. B. start-shell-msvc2013.bat oder start-shell-msvc2013-x64.bat), bestimmt, ob die Compiler-Toolchain auf 32-Bit- oder 64-Bit-Builds abzielt. Um einen 64-Bit-Build zu erstellen beachten Sie, dass Sie mit --target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 konfigurieren müssen. 

Da die POSIX NSPR-Emulation für Windows nicht verfügbar ist, muss eine funktionierende Version von NSPR für Ihren Build verfügbar sein. Die einfachste Option ist die Konfiguration mit --enable-nspr-build. Diese Konfigurationsoption erstellt die In-Tree-Version von NSPR, die Sie wahrscheinlich verwenden möchten. Da SpiderMonkey neuere NSPR-Symbole verwendet, funktioniert der mit Ihrem Betriebssystem ausgelieferte NSPR wahrscheinlich nicht.

Wenn --enable-nspr-build nicht funktioniert, teilen Sie configure explizit mit, wo es NSPR findet, indem Sie die Konfigurationsoptionen -with-nspr-cflags und --with-nspr-libs verwenden. Angenommen, Ihr lokaler NSPR wurde in C:/mozilla-build/msys/local installiert:

./configure --with-nspr-cflags="-IC:/mozilla-build/msys/local/include" \
            --with-nspr-libs="C:/mozilla-build/msys/local/lib/libnspr4.a \
                              C:/mozilla-build/msys/local/lib/libplds4.a \
                              C:/mozilla-build/msys/local/lib/libplc4.a"

Sollten Sie beim Laden von Symbolen oder der dynamischen Bibliothek Fehler erhalten, können Sie erzwingen den korrekten NSPR mit:

PATH="$PATH;C:/mozilla-build/msys/local/lib/" ./js

zu laden.

Angeben der Installationsverzeichnisse

make install legt Dateien standardmäßig in den folgenden Verzeichnissen ab. Sie können dies überschreiben, indem Sie Optionen an das configure-Skript übergeben:

Was es ist Wo es abgelegt wird configure Option
ausführbare Dateien, Shell-Skripte /usr/local/bin --bindir
Bibliotheken, Daten /usr/local/lib --libdir
architekturunabhängige Daten /usr/local/share --sharedir
C-Header-Dateien /usr/local/include --includedir

Der Einfachhalt halber können Sie dem configure Script (Konfigurationsskript) eine Option der Form --prefix=<PREFIXDIR> übergeben, die <PREFIXDIR> für /usr/local in allen obigen Einstellungen in einem Schritt ersetzt. Dies ist normalerweise die am wenigsten problematische Sache, da es die typische Anordnung von lib, bin und dem Rest beibehält. 

Hinweis: Alle Verzeichnisse, die Sie zur configure übergeben, werden im generierten makefile aufgezeichnet, sodass Sie sie erst erneut angeben müssen, wenn Sie configure erneut ausführen.

SpiderMonkey als statische Bibliothek erstellen

Standardmäßig wird SpiderMonkey als gemeinsam genutzte Bibliothek erstellt. Sie können SpiderMonkey jedoch als statische Bibliothek erstellen, indem Sie beim Ausführen von configure das Flag --disable-shared-js angeben. 

Angeben der Compiler und Compiler Flags

Wenn Sie einen anderen Compiler verwenden möchten als den, den das configure -Skript standardmäßig für Sie auswählt, können Sie die CXX-Variable in der Umgebung festlegen, wenn Sie configure ausführen. Dadurch werden die Werte gespeichert, die Sie im generierten Makefile angegeben haben. Wenn Sie diese Makefile einmal festgelegt haben, müssen Sie dies erst wieder tun, wenn Sie configure rneut ausführen.

Wenn Sie bestimmte Flags an den Compiler übergeben möchten, können Sie die CXXFLAGS -Umgebungsvariable beim Ausführen von configure festlegen. Wenn Sie beispielsweise die GNU-Toolchain verwenden, wird im Folgenden das Flag -g3 an den Compiler übergeben, wodurch Debug-Informationen zu Makros ausgegeben werden. Dann können Sie diese Makros in gdb -Befehlen verwenden:

$ CXXFLAGS=-g3 $SRC/configure
...
checking whether the C++ compiler (c++ -g3 ) works... yes
...
$

Um eine 32-Bit Version auf einem 64-Bit Linux System zu erstellen können Sie Folgendes verwenden:

PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CC="gcc -m32" CXX="g++ -m32" AR=ar $SRC/configure --target=i686-pc-linux

Um eine 64-Bit Version auf einem 32-Bit Mac System (bspw. Mac OS X 10.5) zu erstellen können Sie Folgendes verwenden:

AR=ar CC="gcc -m64" CXX="g++ -m64" ../configure --target=x86_64-apple-darwin10.0.0

Um eine 64-Bit Version für Windows zu erstellen können Sie Folgendes verwenden:

$SRC/configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32
Hinweis: Sie müssen Ihre MozillaBuild Shell mit dem korrekten -x64.bat Skript gestartet haben, damit sich die 64-Bit Compiler in Ihrem PATH befinden.

Die Compiler und Flags, die Sie configure (Konfiguration) übergeben, werden in der generierten Makefile aufgezeichnet. Sie müssen diese daher erst wieder angeben, wenn Sie configure erneut ausführen.

Erstellung Ihrer Anwendung

Während "Wie können Sie eine komplette Anwendung erstellen" für dieses Dokument eindeutig nicht möglich ist, hier ein paar Tipps, die Ihnen dabei helfen werden:

  • Die SpideMonkey Entwickler ändern häufig und absichtlich die JSAPI ABI. Sie können keine für eine Version / Konfiguration von JSAPI erstellten Header verwenden, um Objektdateien zu erstellen, die mit anderen verknüpft sind.
  • Die Unterstüztung für JS_THREADSAFE wurde kürzlich eingestellt und threadsafe Builds sind jetzt standardmäßig aktiviert.
  • Das unten beschriebene js-config Skript ist die empfohlene Methode, um korrekte Include-Pfade, erforderliche Bibliotheken usw. zu bestimmen, damit Ihre Einbettung während der Kompilierung verwendet werden kann. Wir empfehlen dringend, das js-config Skript aus dem Makefile Ihrer Einbettung aufzurufen, um Ihre CFLAGS, LDFLAGS usw einzustellen.
  • Um SpiderMonkey in einem anderen Verzeichnis als dem Standard zu installieren, müssen Sie die configure --prefix Option, wie oben beschrieben, verwenden. Andernfalls kann der Header in js-config.h oder das Skript js-config beschädigt werden.
  • Some features detected by the configure script do not work for cross-compilation.

Using the js-config script

In addition to the SpiderMonkey libraries, header files, and shell, the SpiderMonkey build also produces a shell script named js-config which other build systems can use to find out how to compile code using the SpiderMonkey APIs, and how to link with the SpiderMonkey libraries.

Note: In SpiderMonkey 1.8.5, the js-config script is not generated properly on many platforms. If the instructions below do not work, you can try this workaround.

When invoked with the --cflags option, js-config prints the flags that you should pass to the C compiler when compiling files that use the SpiderMonkey API. These flags ensure the compiler will find the SpiderMonkey header files.

$ ./js-config --cflags # Example output: -I/usr/local/include/js -I/usr/include/nspr

When invoked with the --libs option, js-config prints the flags that you should pass to the C compiler when linking an executable or shared library that uses SpiderMonkey. These flags ensure the compiler will find the SpiderMonkey libraries, along with any libraries that SpiderMonkey itself depends upon (like NSPR).

$ ./js-config --libs # Example output: -L/usr/local/lib -lmozjs -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm  -lm -ldl

Testing SpiderMonkey

  • Run ${BUILDDIR}/dist/bin/js Y.js and check if appropriate output is printed. (It should say: 5! is 120.)

  • Run the main test suite by running ./tests/jstests.py ${BUILDDIR}/dist/bin/js

  • Run JIT-specific tests by running: ./jit-test/jit_test.py ${BUILDDIR}/dist/bin/js

Building SpiderMonkey 1.8 or earlier

Use these instructions to build SpiderMonkey from an official source release or from the old CVS repository. To build the latest SpiderMonkey sources from Mercurial, see Building SpiderMonkey above.

SpiderMonkey is easy to build from source if you have the usual Mozilla build prerequisites installed. Before you begin, make sure you have right build tools for your computer: LinuxWindowsMacothers.

First, download a SpiderMonkey source distribution, such as SpiderMonkey 1.8 Release Candidate 1.

To build, use these commands:

tar xvzf js-1.8.0-rc1.tar.gz
cd js/src
make -f Makefile.ref

This builds a debug version of SpiderMonkey. All build files are created in a subdirectory named depending on your system (for example,Linux_All_DBG.OBJ if you are on Linux). To install this build on your system, see SpiderMonkey installation instructions.

To build an optimized (non-debug) version of SpiderMonkey:

make BUILD_OPT=1 -f Makefile.ref

To build a thread-safe version of SpiderMonkey:

make JS_DIST=/full/path/to/directory/containing/nspr JS_THREADSAFE=1 -f Makefile.ref

Schlagwörter des Dokuments und Mitwirkende

 Mitwirkende an dieser Seite: mweitze
 Zuletzt aktualisiert von: mweitze,