> On windows there is no bash or posix shell

Part of the language builtin to my build system provides ways of running commands without a shell.

> there is no gcc or a compiler which takes gcc-like options,

No, but there is MSVC. You just need to abstract the compiler and compiler flags. CMake did it, so why can't I?

> there's no posix compliant or gnu compliant make.

I don't need a make, and neither should redo. My build system will not be like CMake in that it will generate build files for something else; it will execute them itself. No make necessary. In fact, I could implement a make easily with my build system; just a parser would be necessary.

> If you plan on making a build system, it has to take a lot of things and provide an abstraction layer over them to make them work for windows. I say forget it, it's a waste of effort, just make it work on linux and by extension (through WSL or mingw or whatever) you get windows.

I don't think it's a waste of effort. People on Windows deserve a good build system too. In fact, not having a good one means that they are dependent on Microsoft. I'd like to help them reduce that dependence.

> One of the best tests of a build system I've found has been to get a build system to build an executable and run it to produce an output which is then consumed as part of the build process. With pure make, this is purely awful and requires either generating a bunch of rules or lots of boilerplate, and generally it's easy to get wrong. With redo I got this working with relatively little work and got it to work with cross-builds.

It's not hard to get make to do that. See [1] and [2].

> In my adventures with redo, the biggest obstacle to hermetic builds that I've found aside from just the environment (env vars) has been compilers.

Yes, but however it's done, it's still easiest in a self-contained system, IMO.

> Surely a better build system would need some form of overhaul to the interfaces provided by compilers? (Or, some re-implementation of some compiler features so you can spoon-feed a compiler the exact flags to ensure it behaves predictably even if the environment changes.)

The build system should carefully control the environment. In fact, it should make sure the environment is empty. (There are details, but in general...) That's the biggest thing to make sure the compiler does not act weird.

You should also do the build in a separate directory and copy needed files into the directory. Then check all commands and their arguments for possible files before running them. This is one reason why depending on an outside shell is not ideal.

Hermetic builds won't ever be perfect, but you can make it 80% of the way with only a few things.

> TFA?

"The Famous Article". It refers to the link under discussion on HN. In this case, it refers to the apenwarr redo.

> Okay, so you mean dynamically generated .do files.

Not just that. Those were just an example of how dynamic dependencies are already awkward in redo. There are countless other uses for dynamic dependencies. To give you a taste, my build system will actually be able to build a distributed system, i.e., it will be able to be used for DevOps deployment, and it will be easy.

Surely redo can as well, but as I've thought about how to do that, it seems awkward. Perhaps you can prove me wrong?

> Why finnicky? In the usual case you DON'T want anything other than just timestamps and hashes, it works for all cases, albeit slowly for some. If you NEED to customize it, you have to pull out the special tools but then you just wrap that in some little utility and mostly forget about it.

Finicky because as far as I can tell, the build database in redo is modified by multiple commands over a build. This can cause problems should a problem occur with the database mid-build. In a self-contained system, the database is in-memory during the entire build and only written out to disk once the build is done, which can then be used as a sort of "commit" of the build, marking it as finished.

There are other reasons, but that's the first that comes to mind.

> What do YOU think are the obstacles to hermetic builds? I already know what I've found but I'm always looking for more input.

I think a good paper to read would be the Dolstra thesis on Nix. [3] If you consider Nix a build system (not just a package manager), it goes further than even Bazel. The thesis should be a good place to start.

[1]: https://git.yzena.com/gavin/bc/src/branch/master/Makefile.in...

[2]: https://git.yzena.com/gavin/bc/src/branch/master/configure.s...

[3]: https://edolstra.github.io/pubs/phd-thesis.pdf