Hey Anatol, please also take a look at https://groups.google.com/a/chromium.org/d/forum/chromium-packagers which is specifically for packagers and also includes V8/gyp packaging issues.
Feel free to take a look at how Gentoo does things, e.g. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/v8/v8-3.21.12.1.ebuild?revision=1.1&view=markup . It uses tarballs from https://gsdview.appspot.com/chromium-browser-official/ which I highly recommend. Jakob is absolutely right about ABI issues, and so make sure to also read https://groups.google.com/d/msg/linux.gentoo.dev/UTYTzr0eRHs/F5u1ZiLl3nIJwhere Gentoo is actually switching away from v8 shared library. I see some good changes related to this, e.g. starting with better API stability like https://groups.google.com/d/msg/v8-users/jq8k9s4xEu8/N-es0or3uz4J - and I hope as v8 further matures, we'll eventually get to a point where it can provide a more stable ABI (I'm potentially interested in helping with this). There is a pretty strong concern for that not to slow down development of v8, so please keep that in mind. Paweł On Fri, Oct 4, 2013 at 1:17 AM, Jakob Kummerow <[email protected]>wrote: > In addition to what has been said already: > > 1) The V8 build does not automatically pull in either ICU or GYP. You have > to explicitly run "make dependencies" to download them, which is merely a > convenience feature. So there's no need to "turn that off" -- simply run > "make native" or "make ia32.release" directly. > It's true that the build depends on GYP being in the right place. I > suggest you create a tarball for your distro that contains it already (I > think Gentoo does something similar). > > 2) GYP can be a pain, yes, but it's pretty powerful for cross-platform > builds. A plain Makefile build wouldn't work on Windows and Mac. I don't > know why Chromium doesn't use cmake or some other cross-platform build > system; that decision has been made long before I joined the project, but I > assume there have been good reasons. > > 3) While Linux is great for many reasons and generally worthy of support > IMHO, the V8 team's top priority is to make a great JS engine. If you have > identified something that you think should be improved to ease embedders' > or packagers' lives, feel free to contribute a patch yourself ( > https://code.google.com/p/v8/wiki/Contributing) -- as long as it's not > too intrusive, it'll likely be accepted. > > 4) From a release management point of view, V8 doesn't follow the behavior > you may be expecting from a shared system library. When packaging it for > any distro, please make sure you know what you're doing, in particular > which versions you're offering to your users and how you handle ABI > dependencies. > > > On Fri, Oct 4, 2013 at 8:55 AM, Jochen Eisinger <[email protected]>wrote: > >> >> >> >> On Fri, Oct 4, 2013 at 8:25 AM, Anatol Pomozov >> <[email protected]>wrote: >> >>> Hi >>> >>> Thanks for your response. >>> >>> On Thu, Oct 3, 2013 at 10:35 PM, Louis Santillan <[email protected]> >>> wrote: >>> > 1) gyp is a hard dependency. ICU is not. I'm not aware of gyp being >>> > available as a stand alone package on any Linux I use. >>> >>> Ubuntu https://launchpad.net/ubuntu/+source/gyp >>> Arch https://aur.archlinux.org/packages/gyp-svn/ >>> Homebrew formula, although not accepted >>> https://github.com/mxcl/homebrew/pull/11776 >>> >>> > Personally, I >>> > hate it. I wish Chromium/v8 team would go to a plain Makefile build >>> > system. But, its their project, not mine. Use the following in your >>> > v8 pull folder to get around having to do a 'make dependencies': >>> > svn co http://gyp.googlecode.com/svn/trunk build/gyp >>> > >>> > 2) Most of your questions about ICU are answered here >>> > <https://code.google.com/p/v8/wiki/I18NSupport>. The short, you can >>> > use >>> > make use_system_icu=1 >>> > or >>> > make i18nsupport=off >>> >>> Thanks for the document. I tried both options. i18nsupport=off works >>> fine, but use_system_icu=1 does not do what I expect. use_system_icu=1 >>> still compiles third_party/icu and link libv8.so against icu 46: >>> >>> $ nm src/v8-3.22.7/out/x64.release/lib.target/libv8.so | grep -w U | >>> grep icu >>> U _ZN6icu_4610DateFormat19getAvailableLocalesERi >>> U _ZN6icu_4611FormattableC1Ev >>> U _ZN6icu_4611FormattableD1Ev >>> U _ZN6icu_4611StringPieceC1EPKc >>> ............ >>> >>> use_system_icu is a gyp variable. You need to set it as environment >> variable, i.e. >> >> export GYP_DEFINES="use_system_icu=1" >> make >> >> Note that this still requires the third_party/icu to be checked out >> (technically, we just need the icu.gyp file. You can also copy the icu.gyp >> file somewhere else and point icu_gyp_path to it). >> >> If you cross compile, the system ICU will just be used for the target. >> During the build, v8 will also be compiled for the host, and for the host, >> the packaged ICU will be used. >> >> best >> -jochen >> >> >>> > >>> > 3) See #1. >>> > >>> > >>> > -L >>> > >>> > On Thu, Oct 3, 2013 at 1:49 PM, Anatol Pomozov < >>> [email protected]> wrote: >>> >> Hi, >>> >> >>> >> I am speaking from Linux Arch package manager point of view who wants >>> to >>> >> make a great v8 package for its favorite distro. >>> >> >>> >> When I build v8 following things look non-typical for me: >>> >> >>> >> 1) v8 build process pulls gyp and ICU sources from a third_party >>> repo. I >>> >> understand that you need it for users who has no tools installed >>> (e.g. on >>> >> Windows) but Linux/OSX developers use package managers actively. The >>> package >>> >> managers usually include these tools in their repos/PPA/.. In this >>> build >>> >> process should not pull any third-party projects. It should use >>> 'system' >>> >> version of the tools. For example Arch has packages both for GYP and >>> ICU. Is >>> >> there any way to "turn-off" dependency pull/build? >>> >> >>> >> 2) What is more important is that system version of ICU differs from >>> what v8 >>> >> uses. Arch has latest stable version (51) and v8 pulls version 46. >>> Why V8 >>> >> does not use the latest ICU version? Instead of going into shared >>> libraries >>> >> hell and having multiple version of libicu*.so I would prefer that >>> packages >>> >> use the same version (i.e. 51). Is there any patch that ports v8 to >>> ICU51? >>> >> It would be really great if I can combine it with #1, avoid ICU >>> compilation >>> >> and instead use system version of ICU library. >>> >> >>> >> Bottom line: how to compile current v8 HEAD against system ICU >>> version 51 >>> >> (and btw 52 will be released really soon). >>> >> >>> >> >>> >> 3) This is a minor issue though. Have you guys though about making >>> your >>> >> build Python3 friendly? You don't have python extensions so most >>> likely it >>> >> will be easy to make the scripts both 2.7 and 3.3 compatible. This >>> will make >>> >> life easier for those who moved to Python3.3 as a default version. >>> >> >>> >> -- >>> >> -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
