41–50 of 73 posts
Another NIH build tool? Never heard of it, and ninja is the only way to build C++20 modules alongside CMake. Then again, that is something that Chromium probably will never bother with.
Wasn't ninja invented by a Google employee?
Earlier quoted context omitted.
Not really relevant here, but this is actually exactly how it's done in embedded systems like Yocto, everything from gcc, make, etc. is built from source (I believe the host compiler is used in a 3-stage bootstrapping process for gcc). And in these cases you really see the impact of internal dependencies (building rust/llvm takes around 30-40% of the entire build). The upside is that you can patch and debug absolutel…
You mean it’s consistent on the machine code level and this allows patching and debugging more easily? Trying to understand..
Earlier quoted context omitted.
If I'm going to compile Chromium from source, I probably want to compile the build system from source.
Why? Would you compile the compiler from source as well? From what? You need to compile the compiler's compiler from source as well, right? Where does it stop? And why is that location more valid of a decision than the one that doesn't require building the build system from source?
Bootstrapping everything is exactly how it's done correctly--and how it's actually done in practice in Guix.
I mean sure if you have a business to run you outsource this part to someone else--but you seem to think it's not done at all.
Supply chain attacks have been happening pretty much non-stop the past years. Think it's a good idea to use binary artifacts you don't know how they were made (and thus what's in them)? Especially for build tools, compilers and interpreters.
>And why is that location more valid of a decision than the one that doesn't require building the build system from source?
Because you only have to review a 250 Byte binary (implementing an assembler) manually. Everything else is indeed built from source, including make, all the way up to Pypy, Go, Java and .NET (and indeed Chromium).
Kinda impressive and terrifying that Chromium needs its own build system. Kinda strange that Bazel was right there, also from Google, and they not only choose not to use it, but also reference it in the name of the new tool.
>Kinda impressive and terrifying that Chromium needs its own build system. This is one area where I think it makes some sense to build your own. Most projects only use a fraction of the capability of a typical build system. The last time I did this I managed the whole thing in just 300 lines of code.
Looks like the Google developer in the discussion is clueless.
Earlier quoted context omitted.
moving to bazel might be a lot more work vs a drop in replacement which is what siso looks like atm.
Yeah, thats fair, but if I understood right- this is a custom built tool to be compatible with Ninja. That work building “yet another build tool” could have gone in to programmatically generating bazel BUILD files. So, there was an active choice here somewhere; we just don’t know all the information as to why effort was diverted away from Bazel and toward building a new tool. I trust them to make good decisions, so I…
Note that Siso uses Starlark ( https://chromium.googlesource.com/infra/infra/+/refs/heads/m... ) which is the build language of Bazel I wonder if the end goal is to use Bazel for Chromium and Siso is an incremental step to get there
Looks like the Google developer in the discussion is clueless.
[flagged]
Earlier quoted context omitted.
moving to bazel might be a lot more work vs a drop in replacement which is what siso looks like atm.
Yeah, thats fair, but if I understood right- this is a custom built tool to be compatible with Ninja. That work building “yet another build tool” could have gone in to programmatically generating bazel BUILD files. So, there was an active choice here somewhere; we just don’t know all the information as to why effort was diverted away from Bazel and toward building a new tool. I trust them to make good decisions, so I…
This tool is substantially less complex than Bazel, nor is it a reimplementation of Bazel. Ninja's whole goal in life is to be a very fast local executor of the command DAG described by a ninja file, and siso's only goal is to be a remote executor of that DAG.
This is overall less complex than their first stabs at remote execution, which involved standing up a proxy server locally and wrapping all ninja commands in a "run a command locally which forwards it to the proxy server which forwards it to the remote backend" script.