[rtpg]

so then my glib question: what is the purpose of this project?

It does look like for some projects it's almost entirely "just declare the dep tree" (https://github.com/allyourcodebase/boringssl), + the tiniest patch.

But what's going on in grpc for example? Like this build file https://github.com/allyourcodebase/grpc/blob/master/build.zi...... why is this build file in this repo? Is the grpc makefile no bueno?

Efforts to pull out information from existing build systems (if possible, ofc) means that you don't have to spend your time _rewriting build scripts_.

I don't know if it's really possible. Maybe this is step .. 4 of 34 to getting there. Just wondering if there's an alternative here that doesn't involve rewriting build scripts

Maybe a part of the pitch here is to just upstream these build scripts so that ones makefile becomes "just" `zig build`? In that case I'd actually like to see (for example) a fork of oyacc using what is figured out in https://github.com/allyourcodebase/yacc to "just" use the build script even in the higher level project.

[flohofwoe]

> so then my glib question: what is the purpose of this project?

The whole point is to massively simplify integrating those libraries into Zig projects by explicitly not having to deal with external build systems or separate C/C++ compiler toolchains.

> Is the grpc makefile no bueno?

Does it work out-of-the-box on Windows? That's usually the first question when encountering a Makefile (and just looking at the first lines of the Makefile, it doesn't, instead it needs to run inside mings: https://github.com/grpc/grpc/blob/a63b3a4d949a7057a0e5443e7a...).

With Zig you usually only need the Zig toolchain, which runs just fine in a regular Windows cmd.exe.

[gravypod]

> With Zig you usually only need the Zig toolchain, which runs just fine in a regular Windows cmd.exe.

It's amazing how complicated we made things with bad software engineering and how good we can make things with good software engineering.

[peesem]

i do like zig and its build system, but i agree that i see little point to the allyourcodebase repositories. you can probably learn about what you _can_ do with the build system through them, but i don't think they're best practice. they just redefine the build graph either statically (harder to update) or through path generation with python or something of the sort (what's the point, it's not contained in the zig build system anymore). i also remember some repositories getting quite outdated, though it seems there's been more effort to keep them updated these days.

the one thing i will blame zig for here is the refusal to make some system to just include all of the files in a directory (hence allyourcodebase's python scripts). it makes sense with zig's import & module system but i think it would probably be a big blocker for some projects that they'd have to manually list out every single C file in their source.

you can currently use the filesystem apis to manually walk through files in your build script, though this is discouraged and will go away with upcoming change of isolating the build script