Xmake: A cross-platform build utility based on Lua

"For instance autotools is largely a relic of back in the days where C++ was C with classes..."

Minor point: autotools is a relic of the days when there were multiple, only somewhat compatible implementation of Unix in common use. Now that the world is a Linux monoculture and most software is installed by end users in the form of pre-built binary packages, the form of portability provided by autotools is no longer needed.

> All others are either defunct, abandoned, or dropped out of favour, or never had any expressive adoption.

So you're agreeing that, if we see a new challenger succeed, we pay the price of fragmentation?

I agree that these sorts of projects rarely gain any real traction.

I don't see that the history of autotools is relevant here. It's still very common to see in the wild.

I think this is sort of the creator/maintainer conflict. Creators hate maven because they have their own idea about how their project should be structured and it’s different from maven’s. Maintainers love maven because they inherit a code base with a canonical structure.

> Coming from maven I can say the opposite.

To be fair, maven is in a class of its own with regards of designing a tool that is the worse of both worlds.

And your point is that it would be better to write pre/postprocessing logic in the build system? That sounds like a recipe for disaster and slow build times.

What I would advise is to think carefully about your custom pre-/post-processing tasks in light of how they will affect componentization and reuse. Working with many teams and codebases, it’s been my experience that having a lot of custom code generation or code parsing ties your code to your build system in ways that make it harder to re-use elsewhere, on different platforms or for different products. It also imposes a level of astonishment when analyzing dependencies - libraries that may appear to be largely independent of each other can actually be effectively coupled if one of them has a funky prebuild codegen step that depends on the other. Or coupled to the core build logic and source tree. If you really need the custom build step, and it really needs to be implemented in your build system, I’d encourage you to think about the tools and language you’re using.

If you build it, they will come. Don’t be surprised to find out that a good chunk of your business logic winds up in build files rather than what you would typically think of and analyze as your ‘source’.

I also have had bad experiences with scons and much prefer declarative build systems with options to escape to external executables when you really can't help it. Because the vast majority of the time, you can actually help it.

Having friction to using bespoke compilation steps is a feature in my experience, it means that devs will use standard build elements whenever possible and if a problem occurs the "wildcard" external binaries can more easily be probed and reviewed.

People are downvoting but it’s 100% true. A build system targeting primarily C/C++ requiring an interpreter and runtime dependencies is a no-go for quite a number of projects. There’s a reason they were written in C/C++ in the first place, and the fact that a lot of people install via packages (separating build from distribution) is scarcely solace.