On Sun, Aug 6, 2017 at 3:17 AM, Georgi Sotirov <gdsoti...@gmail.com> wrote:

> GCC 4.8 is what ships in Ubuntu Trusty, which is still our main
>> development platform. Usually ensuring that older toolchains are still
>> supported is more difficult (and hence more important) than supporting
>> newer toolchains.
>> Most people build with the bundled clang; GCC support is mostly community
>> driven at this point. The fact that it has been broken for a while until
>> you found it tells you how few people care about it...
> Well, I won't argue here, but still I believe the error reported by GCC
> 7.1.0 is something that should be fixed into the sources no matter of the
> compiler used

Absolutely. Feel free to submit a patch.

Unused functions, especially in tests, can just be deleted. (No point in
>> commenting out code that doesn't work, just drop it.)
> Why it is there in first place then?

Probably forgotten in a refactoring.

> Shouldn't it be removed upstream, so I do not have to manage my own
> patches for this?

Absolutely. Feel free to submit a patch.

> I wasn't asking you to learn any new tool or understand V8 version
>> numbering. I was just saying: next time you report a problem, please
>> indicate the version you were using. The git hash of your most recent
>> commit is perfectly fine for that.
> Yes, OK, I though it's clear enough that I cloned the repository, so using
> the most recent version (i.e. or several days old). However, you're right
> it's sometimes important to know the last hash, because changes are
> committed constantly. Nevertheless I do not think this information would
> have been of a match use, because what you wrote there doesn't give me much
> optimism that the problem would be fixed upstream (e.g. it doesn't matter
> much whether I use version 1, 2 or more days old).

Agreed, in this case it didn't make a difference, but we didn't know that
up front; it may well have mattered (if compilation issues get committed at
all, they are usually fixed or reverted in minutes to hours, because they
block everyone else's work).

All I said was: *next time*, please mention the version.

Indeed, there is no "make install". V8 is designed to be embedded/bundled;
>> installing it as a system library does not make much sense.
> Even when eventually it would be shared between several applications?
> Hmm... I'll check what exactly the dependent application requires.

The situation is complicated. V8 evolves quickly, with
usually-ABI-incompatible versions every six weeks, and minor bugfix updates
in between. You'd end up having to recompile dependent applications a lot.
Another issue is that if a user e.g. wants Chromium and node.js on their
system, but the respective current versions of both require different V8
versions, then sharing the V8 package is simply impossible. You'd have to
have support for several versions of V8 installed side by side, with each
application using one of them, so you effectively wouldn't get any sharing.
Also, Node.js often floats additional patches on top of upstream V8, which
would also be very difficult to support in a shared-system-library
deployment model.

As a data point: AFAIK Gentoo offered a V8 package for a while, and then
dropped it because it wasn't worth it.

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

Reply via email to