GypPathToUniqueOutput from ninja.py

[indutny]

Original GYP puts compilation results to obj/${intPrefix} dir if they are of some specific types (which differ by platform).

I'm not sure how to fix it at this moment, but node uses this feature of GYP when linking to v8/openssl. We need to fix it somehow.

cc @refack maybe you have an idea?

[refack]

Do you have a tree example? On which platform?
(I assume not Windows since I was able to link node.exe on Windows)

[indutny]

Not windows, actually. https://github.com/nodejs/node/blob/940b5303bef7aee9b24214c62e4b6f182f23f82a/node.gyp#L386-L399

It is different on Mac and other Unixes. On Mac GYP puts everything into ./out/Release be it libv8_base.a or whatever, on unixes it will put .a files in obj/... folders. I assume that this is because GYP prevents name conflicts... but still, it appears to work without it at the moment.

[indutny]

The problem is that node.gyp expects the .a file to be at different location on Linux and FreeBSD.

[indutny]

See: http://codereview.chromium.org/9139003

[indutny]

@evmar sorry to bring you in here without asking you first, I hope this is ok.

You have reviewed that original CL for placing GYP outputs in different dirs on different platforms. May I ask you to share with us what downsides may be in placing everything in ./out/Release? I suppose it comes down to multiple-toolset, but otherwise is there anything else to consider?

[indutny]

Will placing outputs to unique paths for toolset !== 'target' be enough to mitigate this?

[refack]

I'm cranking up my hackintosh VM, or do you think a vanilla FreeBSD will be good enough/better? P.S. I'm practically living in the MIT campus so BSD brrrr 😒 MIT yeeeaaahhh👩‍🎤

…

On Mar 21, 2017 14:37, "Fedor Indutny" ***@***.***> wrote: Not windows, actually. https://github.com/nodejs/node/blob/ 940b5303bef7aee9b24214c62e4b6f182f23f82a/node.gyp#L386-L399 It is different on Mac and other Unixes. On Mac GYP puts everything into ./out/Release be it libv8_base.a or whatever, on unixes it will put .a files in obj/... folders. I assume that this is because GYP prevents name conflicts... but still, it appears to work without it at the moment. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF6syyj1S1rhwBjMM6xGyNbh01OsF9fks5roBjpgaJpZM4Mj0bi> .

[evmar]

@nico is the gyp+mac wizard who can maybe explain this decision.

I don't really understand this node code, so this advice is vague, but:

• I think the design of gyp is that build rules shouldn't care where static libraries are written (the actual path the library ends up at is meant to be an internal implementation detail).
• I would think the proper place for library-specific logic would be on the library's build rule, not on the rule that depends on the library.
• Chrome uses OpenSSL (well, BoringSSL, but that's a fork of OpenSSL) and it doesn't need this special casing. Do you know why?

[indutny]

I absolutely agree with all points here. The reason why node uses it is because addons (read shared_library) need to access OpenSSL and V8 functions. Hence, node.gyp has whole-archive linker directives. These directives will make all symbols available in the final executable, however they need the path to the static library which is placed somewhere in either product or object dir.

Anyway, the question is more about whether putting everything with toolset == 'target' in ./out/Release is a bad pattern, and if it should be avoided?

[indutny]

( @evmar thanks for coming here with answers! We appreciate it! )

[evmar]

My vague recollection of the history is that we originally only worked on Linux and put the archives in the subdirectories because otherwise they'd need to be globally unique names across the project. And then for some Mac reason we needed to put the archives not in subdirectories, which meant users now must be careful to use globally unique names. So I think it'd be harmless to put them all in the top-level directory on all platforms. Just kinda ugly! But I think @nico knows better than me.

[indutny]

This does not work for projects whose output is either static or shared library, though. I suppose that ideally top-level .gyp file results may be put to ./out/Release, while others may be put to obj subfolders.

[evmar]

(Just another disclaimer that I haven't worked in this area for >5 years, but...) As I recall static_library/shared_library was considered an internal build detail, and there was some other target type (maybe loadable_module?) for variants of those that were considered build output and which would get predictable paths.

[indutny]

Yeah, sounds good then. I was afraid of some unforeseen caveats that I haven't considered. Going to keep it as it is now, and land #38. Thank yoU!

[nico]

Sorry, didn't see this. The history of gyp, in a nutshell, is that @evmar wrote the Ninja generator and it was so good that all the other platforms wanted to use it. So we made it work on other platforms, but we already had other build systems on the other platforms. To make a good case for switching from these other platforms to ninja, we tried to make gyp's ninja generator produce bit-for-bit identical output as the "native" build system on these platforms. So on Mac, gyp/ninja produces ninja files that behave like Xcode (3.1.2) did, and on Win, it produces ninja files that behave like MSVC. That's the only reason for it.

[indutny]

Thank you for informative reply!

[refack]

Ref: nodejs/node#12231 (comment)