I think this makes Chrome build system number four: scons, gyp, ninja, siso.
gyp to gn
gyp could produce ninja files. gn is short for generate ninja. Now gn produces files compatible with siso
Chromium Switching from Ninja to Siso
31–40 of 73 posts
Re: Chromium Switching from Ninja to Siso
#32Another 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.
Re: Chromium Switching from Ninja to Siso
#33Kinda 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.
Re: Chromium Switching from Ninja to Siso
#34Earlier 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?
At least for Linux distros and the likes of Brew, you will need to have Go to have Siso, and so on.
Re: Chromium Switching from Ninja to Siso
#35Earlier 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…
> That work building “yet another build tool” could have gone in to programmatically generating bazel BUILD files.
Google did try that for Android (AOSP). They made a tool that generated thousands? of BUILD files to get AOSP building with Bazel.
But the migration to Bazel was aborted for unknown reasons.
Re: Chromium Switching from Ninja to Siso
#36Re: Chromium Switching from Ninja to Siso
#37Earlier quoted context omitted.
How so? you don't need the go build toolchain installed to use Go binaries.
If I'm going to compile Chromium from source, I probably want to compile the build system from source.
That "probably" is doing a lot of heavy lifting; it's entirely your personal choice and responsibility to build the build system from source. The choice of language for said build system wasn't done for your particular preference.
Anyway, installing Go is easy enough, especially for someone who apparently builds Chromium from source already.
Re: Chromium Switching from Ninja to Siso
#38Another 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?
Re: Chromium Switching from Ninja to Siso
#39Is there an explanation what siso provides that ninja does not?
Yes, if you click the article and read it it tells you.
Re: Chromium Switching from Ninja to Siso
#40Earlier quoted context omitted.
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?
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..