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.

Reply via email to