Remove the ninja build-from-source - #1742
Conversation
651ed7a to
6979cba
Compare
|
If @juj wants the build-from-source for the compilers to allow code signing and such, and if we are going to start depending on Ninja for building libraries, then he might want to keep the ninja build-from-source for the same reasons. |
I doubt the official ninja binaries are are problem though, right? Also, even in a Ninja build its still Visual Studio (the official MS binaries) that are doing all the compiling and linking. The version of ninja.exe used to invoke the tools I don't think plays any role in the resulting signature/binary right? |
🤷 Dunno. Are they signed?
Yeah, mostly I think the issue is that they don't want to ship any binaries to run on the users' machine that aren't signed, since they may be blocked by the OS. So if they are packaging all possible target libraries ahead of time, then it's not an issue. But if some libraries get built on demand, the ninja binary would need to be signed by someone. |
6979cba to
202c1bc
Compare
|
Sorry, to be clear this version of ninja should never be used to build anything during emcc compiling. emscripten itself does not used ninja by default. When we supply ninja here its really in service of building things like binaryen and llvm from source. |
|
I have no current plans to enable EMCC_USE_NINJA by default. |
202c1bc to
9051806
Compare
Now that we have ninja binaries available for install (See #1105), I don't think we need to be able to build it from source anymore. We can treat ninja more like node and/or python and just depend on the binary version of it.
9051806 to
49be415
Compare
|
It would be nice to keep the ability to build Ninja from source. E.g. in case someone suspects a bug (or a performance issue?) in a binary release, they might then be able to easily build from source and compare against the precompiled one. The naming of the prebuilt vs compiled ninja packages differs well with the As long as ninja is a dependency only to Emsdk build/packaging time, and won't be needed at Emscripten runtime (our parallel system lib builder is enough?), then it is easy for us at Unity to drop shipping ninja after we've precompiled the SDK package. |
For other third-party tools like node and python we don't tend to support building from source, and ninja is so so simply its hard to imagine ever needing to patch it. So i'm temped to delete this for now and then if we ever need to resurrect it we can.
Thats true, I'm mostly just wanting to cleanup unused stuff here. This stuff doesn't get any testing and has no know current uses so I think its better to delete it and carry the untested code paths.
Correct. This ninja would only be used for building bianryen and llvm, not shipped to users of emscripten. |
In my own workflow, I do currently build Ninja from source along all the other tools, so it would be nice for me to be able to retain that. |
Fair enough. I'll leave it here for now. Can you persuade you to switch the using the prebuilt ninja (if it make it trivial use it?) at some point? (i.e. do you have an attachment to the built-from-source version?) |
Now that we have ninja binaries available for install (See #1105), I don't think we need to be able to build it from source anymore.
We can treat ninja more like node and/or python and just depend on the binary version of it.
Also, add missing arm64 binaries for ninja for windows and linux, making this binary available on all three OSes on both architectures.