Make v8 project more package managers friendly

[Anatol Pomozov]

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.

[Louis Santillan]

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. 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

3) See #1.


-L

> --
> --
> v8-users mailing list
> v8-u...@googlegroups.com
> 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 v8-users+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Anatol Pomozov]

Hi

Thanks for your response.

On Thu, Oct 3, 2013 at 10:35 PM, Louis Santillan <lpsa...@gmail.com> 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
............

> You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/NK4yYCo6JUk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

[Jochen Eisinger]

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

[Jakob Kummerow]

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. 

[Paweł Hajdan, Jr.]

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/F5u1ZiLl3nIJ where 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ł

--

[Louis Santillan]

Jochen,

Could you elaborate on "copy the icu.gyp file somewhere else and point
icu_gyp_path to it"? I hate pulling 100's of MB that I'm not using.

Would 'svn co icu46/icu.gyp' suffice? I'm building with i18nsupport=off.

-L

[Anatol Pomozov]

Hi

Thanks everyone, and especially Pawel. I was using gentoo package as a
great source of information.

Here the package
https://github.com/anatol/archpackages/blob/master/v8/PKGBUILD

At this point the package builds fine with system ICU (version 51) but
a few internationalization tests are failing.

On Fri, Oct 4, 2013 at 10:51 PM, Louis Santillan <lpsa...@gmail.com> wrote:
> Jochen,
>
> Could you elaborate on "copy the icu.gyp file somewhere else and point
> icu_gyp_path to it"? I hate pulling 100's of MB that I'm not using.
>
> Would 'svn co icu46/icu.gyp' suffice? I'm building with i18nsupport=off.

I am not using 'make dependencies' and do

mkdir -p third_party/icu
wget http://src.chromium.org/chrome/trunk/deps/third_party/icu46/icu.gyp
-O third_party/icu/icu.gyp

that seems enough.

[Jakob Kummerow]

Are you sure you're doing your users (and yourself) a favor by shipping trunk builds?

[Anatol Pomozov]

Hi

On Sat, Oct 5, 2013 at 6:02 AM, Jakob Kummerow <jkum...@chromium.org> wrote:
> Are you sure you're doing your users (and yourself) a favor by shipping
> trunk builds?

When you say trunk build do you mean that 3.22.8 is unstable release?
(Sorry I am not very good at chome developers lingo).

If 3.22.8 is beta version what is the stable version then? I looked at
https://code.google.com/p/v8/ and could not find any relevant
information. I see this page though http://omahaproxy.appspot.com/
that says stable chrome on linux uses version 3.20.17.13. Does it mean
Linux packages should provide version 3.20.17.13?

[Jochen Eisinger]

Right, checking out the icu.gyp only is enough if you disable i18n. Putting it in third_party/icu is probably the easiest option.

best

-jochen

[Jakob Kummerow]

On Sat, Oct 5, 2013 at 11:33 PM, Anatol Pomozov <anatol....@gmail.com> wrote:

Hi

On Sat, Oct 5, 2013 at 6:02 AM, Jakob Kummerow <jkum...@chromium.org> wrote:
> Are you sure you're doing your users (and yourself) a favor by shipping
> trunk builds?

When you say trunk build do you mean that 3.22.8 is unstable release?

Yes. Highly unstable. 

 

(Sorry I am not very good at chome developers lingo).

If 3.22.8 is beta version

It's not even beta. It's trunk, as in: daily development snapshot. Some projects call this "nightly build".

 

what is the stable version then? I looked at
https://code.google.com/p/v8/ and could not find any relevant
information. I see this page though http://omahaproxy.appspot.com/
that says stable chrome on linux uses version 3.20.17.13. Does it mean
Linux packages should provide version 3.20.17.13?

Yes, following the Chrome stable channel is a good idea. It's fine to take the tip of the respective branch -- since Chrome stable isn't updated daily, there are sometimes a few fixes on the branch that Chrome hasn't picked up yet. E.g. right now the tip of the 3.20 branch is 3.20.17.15.