On Thu, Sep 8, 2011 at 10:14, Jakob Kummerow <[email protected]> wrote:
> > > 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)? >> > Update: as of v8 r9196 (will be in version 3.6.2), we have a gyp variable called soname_version. Setting that to "1.2.3" (e.g. by calling "make -j16 ia32.release library=shared soname_version=1.2.3", or by putting it into GYP_DEFINES before manually running gyp) you'll get a "out/ia32.release/lib.target/libv8-1.2.3.so". I know that this is not a perfect solution, but I hope that it's good enough. Possible improvements include: - detect the version number automatically by analyzing src/version.cc. I'm not sure whether that would add much value (when a Linux distro builds a package, it should know the version of the package anyway, Gentoo ebuilds do for sure), nor whether it's desirable, as it would take away some flexibility. - change the naming scheme to libv8.so.1.2.3 as is customary for libraries. That, however, would require patching GYP to support this (which I don't feel a particular desire to do). 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
