In a change committed yesterday, the v8 shell was disabled with the comment "do not install shell (it's not intended to be installed; d8 is)". d8 used to be installed with v8, but now isn't, and there is no ebuild or use flag for it. I understand not installing their little example shell, but d8 is extremely useful for applications like my company's where we would rather not link directly against libv8 and just want to run some javascript. I tried creating a patch to add a "d8" use flag, but it didn't work terribly well, and kept installing d8 to the root of the image directory. I've attached what I got in case it's helpful, and since I'd like to at least get some guidance on what I'm doing wrong so I can learn from the experience. Reproducible: Always Steps to Reproduce: 1. emerge =dev-lang/v8-3.4.14.28 2. d8 Actual Results: d8: command not found Expected Results: V8 version 3.4.14.28 [D8 light using shared library] d8>
Created attachment 289781 [details, diff] attempt to patch in a d8 use flag
A more generic option for the use flag might be something like 'shell' instead of 'd8'. I'm hoping to have a similar one added to dev-lang/spidermonkey to re-institute the 'js' shell.
v8-3.4 doesn't even build d8 because it's broken upstream. v8-3.6 (hard masked) builds and installs v8. Sorry for the inconvenience, feel free to tell upstream what you think. By the way, v8-3.4 is *not* affected by the change you've mentioned (really, please see the ChangeLog and the list of touched files above that message).
Ah, the changelog is definitely my mistake. Sorry about that. I am still slightly confused about why when I do a "scons d8" the resulting executable seems to work (at least runs - I understand that's not even remotely close to the same thing). I will take my search upstream. Sorry if I seemed at all accusatory - I really appreciate all the hard work you're all putting in here, and will definitely be looking at 4.6. Thank you!
(In reply to comment #4) > I am still slightly confused about why when I do a "scons d8" the resulting > executable seems to work (at least runs - I understand that's not even remotely > close to the same thing). A possible explanation: Simply running "scons d8" results in a statically linked version of v8, whereas the ebuild builds a dynamically linked (shared) version. Upstream tends to take better care of the static version since it is used by the Chrome web browser.
Ah, I see. Thanks for the reply, and makes sense. Also, pleased to report that upgrading to the 3.6* line did definitely bring back a working d8 binary, in case anyone stumbles across this ticket and doesn't catch that. Again, thanks for the good work guys.
