zig build system

[andrewrk]

This competes with cmake, autotools, ninja, make, etc. The user creates build.zig, a script which imports a library and adds things to build. The idea is for this to actually be an even better way to build even C and C++ projects than cmake, autotools, or make itself. And of course it will support building zig projects.

It should also do package management and resource file management which would provide C and C++ projects a way to have painless dependencies like other languages have.

build.zig can of course have arbitrary logic in it, but at the heart is a library that zig will provide such that targets can be defined in a declarative way, and repeated executions of the build script will do no more work than necessary.

• hello world build system
• if build succeeds, delete the ./build program
• upgrade tetris project to use the build system
• upgrade clashos project to use the build system
• make --zig-verbose do the firehose and --verbose just print the commands before executing them
• use a proper unique filename for linker script and delete it on success
• build a C project with it
• support building an object
• support building a library
• avoid unnecessary work such as recompiling a zig exe that has not changed, recompiling the build script itself if it has not changed
• support the concept of multiple targets and arbitrary targets like "Run my tests"
• add support for build options

[fsaintjacques]

Would it be possible to create a "tools" label.

[andrewrk]

Done.

[fsaintjacques]

What's your opinion on the rust way?

My shopping list would go as follow:

• Declarative by default, programability should be used in extreme cases
• Dependency management, possibly with central repository, sources are pulled not object files
• Mandatory formatting (go fmt)
• Mandatory documentation (javadoc/doxygen), test phase requires that every pub function/struct is documented
• Standardize directory structure: {src,examples,tests,README.md}

I do not want that C/C++ build system limitations impede/leak on this tool.

Finally, since this is zig lang, the build tool has to be named zag.

[andrewrk]

Declarative by default, programability should be used in extreme cases

On board. Zig has no preprocessor, no macros, instead has a declarative approach to solving these problems.

Dependency management, possibly with central repository, sources are pulled not object files

Same except no central repository. Instead there will be a variety of ways to obtain source as well as specifying a hash to ensure that correct dependencies were obtained. At any point you can update a dependency or all dependencies which will update the hashes.

Mandatory formatting (go fmt)

Zig compiler will have an error for mis-indented code (see #35). Hard tabs are already a syntax error. Beyond that, I think we will have zig fmt but it will be left up to the user to decide how to integrate this tool into their development process.

Mandatory documentation (javadoc/doxygen), test phase requires that every pub function/struct is documented

We do have a way to specify documentation comments in the source code, but no docs are automatically generated yet (see #21). I doubt that we will make it mandatory as this leads to pointless documentation (window.setMaximized() // this function sets the window to be maximized). Further, it's not Zig's business to tell the user they have to do more work to get their code to run. This is open for discussion, as are all the other assertions I'm making here.

Standardize directory structure: {src,examples,tests,README.md}

At the very least I think that Zig will recommend a directory structure. I haven't thought about how, if at all, this would be enforced.

I'm starting to think that maybe we could have a zig lint command which would lint a package to make it ready for publishing. It wouldn't actually send the code anywhere; it would simply check directory structure, code formatting, whether things were documented, etc, and print an OK message or errors. You could still depend on the package without going through this step.

I do not want that C/C++ build system limitations impede/leak on this tool.

Do you have any specific limitations in mind?

The way that I see it happening is that we have a declarative way to specify C/C++ targets. Not a DSL; just zig library code that integrates into the build system. We could also add to this library knowledge of how to build other language targets. And then finally a custom target interface. Ideally this build system would be useful no matter what language or platform you were building on.

Finally, since this is zig lang, the build tool has to be named zag.

Cute. But it will probably just be a subcommand of zig: zig build.

[dumblob]

The outlined ideas sound good and I can actually see three directions of development:

1. A lightweight fully multiplatform cmake/make/configure/... like tool which is totally self-contained and has strong metaprogramming capabilities like Premake (metaprogramming would allow writing a tiny module supporting all the needed specialities like code_fmt/doc_gen/auto_test/... of Zig).
2. A very own code_fmt/doc_gen/auto_test/... tool written from scratch and fitting just the needs of Zig (e.g. as Dao did with its daomake).
3. Using Ekam (or rewriting the tool to Zig, but retaining the very same functionality, syntax compatibility and behavior).

My strongest preference would be for the third option (Ekam) as the second option is shit loads of work and testing (will take years due to platform differences as it took daomake) without basically any benefits compared to the other two options. And the first option (Premake) is though a very good one, but still can't catch up with the modern view and simplicity of the third option.

[andrewrk]

Ekam works by exploration. For example, when it encounters a file ending in ".cpp", it tries to compile the file, intercepting system calls to find out its dependencies (e.g. included headers). If some of these are missing, Ekam continues to explore...

While I admire the bravado of this approach, it's pretty antithetical to Zig's principles, which is an explicit, straightforward, low complexity approach to solve problems.

Most of what Ekam does is not necessary when compiling Zig software because in Zig there is a single entry point source file which imports explicitly all the other files it will use.

However, Zig is intended to integrate into a legacy C/C++/native project, and as such it is possible that Zig will plug into the build process in the middle of it. Whether the Zig Build System gets to own the whole build process or not, this should work in a way that is well-understood and not up to heuristics.

I'm actually going for something closer to (1) as outlined above. I see it as a bargaining chip to break into legacy projects. "You're not adding a dependency on Zig, you're trading your cmake dependency for it." Then once people have Zig as a dependency, it becomes easier to want to use it more - at first as a package manager, then maybe to write a simple dev tool, and then possibly implementing some of the project in it.

[dumblob]

Ekam works by exploration. For example, when it encounters a file ending in ".cpp", it tries to compile the file, intercepting system calls to find out its dependencies (e.g. included headers). If some of these are missing, Ekam continues to explore...

If you read further (and the source code), this is just an icing on the cake. The core is, that you can specify everything (including dependencies and any other stuff unrelated to building, but project management, automation, etc.) and do not need to rely on heuristics. Heuristics was though the initial idea and thus it's mentioned at the beginning. But yeah, Kenton is not a good marketing person, so his description might be misleading. Ekam shall play nicely with other build systems, but is not polished enough yet, so it might undergo pretty significant changes. I mentioned Ekam as it's a very modular and KISS approach offering both leisureness and rigidness if needed.

Anyway, if you lean towards (1), I would advocate for Premake 😉.

[andrewrk]

This feature now exists and is a big enough topic that it has its own set of multiple issues.

[0joshuaolson1]

This feature is not documented. Where should general discussion go?

[andrewrk]

Feel free to open issues discussing anything about it. The lack of documentation issue is #367
Documentation for it is in 2 parts: the overview, which will be in the language reference, and the std lib API, which will be solved with #21