Had a laugh watching this section from Tsoding latest Youtube video 
C++ Library that Cracked Networking
Context: Tsoding checks out the ZeroMQ networking library. His chat jokingly asks where the build.zig is and Tsoding proceeds to reveal our genius plan to take over the world Heās on to us guys!
He was quite cynical about it, which I donāt blame him. I think a lot of these build.zig files jumped the shark a bit by pushing too early while the build system is in flux. If projects get burned by the build system API changing, they are going to avoid it even when zig is 1.0 and the experience will be nicer.
Putting it all into the AllYourCodebase org means that people donāt have to deal with the papercuts as things mature.
I really dislike his take. āThey know what they are doingā, who is ātheyā in this context? Andrew, Loris or the community as whole?
As far as I understand, there was no co-ordinated push to put build.zig in every oss project. Individuals put in the work because they believe the build system is good and wanted to share itās benefits.
It may of been annoying for for the repo owners, which is a fair observation, but itās not as deep as tsoding is insinuating.
I didnāt watch the video, but āYou know what you doingā is the line that comes after āTake Off Every āZIGā!!ā in the Zero Wing intro.
You didnāt read the small print when joining this community? You are required to submit at least 1 build.zig to a C/C++ codebase per month.
I empathize that it can be annoying to have someone submit a PR to your repo for a build system youāre not familiar with. We actually had some discussion about this a while back and thatās when we decided to create āallyourcodebaseā so we could still share zig build code without having to āannoyā upstream maintainers. Most of what Tsoding said is true. Itās true we are aware that making Zig good at building C/C++ is great marketing. But, I think his misses the main reason we submit build.zig files, itās not to promote the Zig language (at least not for me), itās to get the benefits that the zig build system provides, namely, cross-compilation support, a package manager, and reducing build dependencies. Promoting zig is just a ābonusā The evidence that this is not only my main reason, but others as well comes from Tsoding himself. After we switched to using allyourcodebase, we no longer promote the zig language in the upstream repository like he was explaining, yet, weāre still creating these build.zig files.
In any case, I find Tsodingās humor entertaining. I think heās got some wrong ideas about Zig but heās very smart/experienced and I think āmostā of his takes/criticisms are, as heād say, ābasedā
IMHO the better approach is to create a non-intrusive project which is just a build.zig.zon and build.zig. The build.zig.zon pulls the original C project, and the build.zig file builds it.
That way you donāt need to hassle the project maintainer with your pet build system (because this not only happens for build.zig, but also for CMakeLists.txt etcā¦) while still having an easy way to build the library.
My own POV / hot take is that C libraries should not come with any build system files at all (e.g. no Makefile, no CMakeLists.txt, no build.zig, no meson.build etcā¦) - since the C/C++ world never agreed on a standard build system (the closest thing is cmake, but enough people hate cmake with a passion that it will never be fully accepted).
PS: I now see that allyourcodebases is exactly that
Yeah I think not having any build files in a C project is a valid approach. Tsoding also has his own build system pattern ānob.cā where you copy the ānob.cā build library into your project and write your build system in C. Itās the same idea as build.zig in reducing build dependencies, since you already need a compiler, if you use that compiler for your build system as well then you only have single dependency. The only downside is the std C library doesnāt help you much, youāll probably miss out on build caching, package management, fetching dependencies, full cross-compilation support, smart parallelism that takes memory into account, coordinated build output, ā¦etc, but, Iād still consider using something like nob in a cases where I couldnāt use build.zig.
I hear where youāre coming from.
I believe Andrew Kelleyās vision was to meet C and C++ developers where they are at. He wanted to allow the code base to remain the same and replace all the Cmake/Make/configure scripts with just one tool.
However, thereās definitely more than one perspective you can have on Tsodingās take. To Tsodingās point, Andrew Kelley has also described the inclusion of build.zig files as an on-ramp to get project maintainers interested in Zig.
While Iāve only been following him for a short period of time, Iām confident Tsoding has been around long enough to see many fad languages come and go. If I put myself in his shoes, I can see myself quickly becoming jaded to any new language (Zig or otherwise) being shoved in my face.
Heās 100% correct, this has been the plan since day one.
Only difference is the plan isnāt to shove it into peopleās faces, itās to entice projects to willingly adopt it by being too useful to ignore.
I think itās funny that the PR is over 2 years old, which he probably excavated for the video to whip up emotions. And it worked when you look at the comments. What you donāt do for clicks.
Yes, thatās the business heās in, without a doubt.
Gotta say I love your approach, Andrew.