On Thu, Sep 8, 2011 at 00:10, Paweł Hajdan, Jr. <[email protected]>wrote:
> On Thu, Aug 25, 2011 at 02:04, Jakob Kummerow <[email protected]>wrote: > >> It's correct that building with SCons is deprecated. That means: Don't put >> any effort into improving the SCons build. >> > > Okay, that sounds reasonable. I was able to do a shared library make build > using "build/gyp_v8 -Dcomponent=shared_library" . Then "make -f > Makefile-ia32 BUILDTYPE=Release" succeeded (for v8-3.5.8). > > Some questions: > > 1. How do I run tests? > If you've built v8 as you've described: tools/test.py --no-build --build-system=gyp --shell=out/Release/d8 --mode=release --arch=ia32 -j16 (adjust -j16 as required for your machine. Setting it to the number of cores (including HT) is fine. Don't set the number too high or you'll get timeouts.) Note: expect this syntax to change slightly over the coming months. Specifically, I expect that the "--no-build" and "--build-system=gyp" parameters will disappear once we've removed support for building with SCons. The easier alternative is to make use of the top-level Makefile, which wraps the gyp build. Then there's only one step required to build and test: make -jX TESTJOBS=-jY component=shared_library ia32.release.check where X is the number of threads for building (default 1) and Y is the number of threads for testing (default 16). You'll find the resulting binaries in "./out/ia32.release/". Instead of "component=shared_library" you can also write "library=shared", the two are equivalent. The target "ia32.release" builds without testing. > 2. How do I enable SONAME (containing a version number)? > No idea. I'm aware that Linux distros want that feature, but I don't know if GYP supports setting the SONAME of built libraries at all. I'm trying to find out more about that. We could possibly ignore the embedded SONAME field and just manually rename the generated .so file to libv8.so.1.2.3 (and create a symlink named libv8.so?), but even that would require a way of making the gyp build aware of the version that's being built. >From the point of view of linking against the shared library, it's unfortunate that v8 makes no ABI compatibility guarantees at all, so currently the best you can do is assume that each version is incompatible with all other versions. I doubt that this situation will change anytime soon, since v8's version numbers are chosen based on date rather than features/changes. > 3. Why is there a different Makefile for each architecture? > Because for daily development work, we need to compile V8 for all architectures all the time (and on the same machine). > Can I just pass the architecture to gyp and let it produce the right > Makefile? > Sure. Take a look at the "GYP file generation targets" in the top-level Makefile for inspiration. I'm happy to include other targets (such as "native"?) into that Makefile. Just tell me what you need, or create a patch yourself and I'll gladly review it. -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
