This idea of having a "front-end" build system and a "back-end" build system is a bit of a throw-back. It is better to integrate the two for better optimization and configuration management.

I don't know if that's true. Don't you gain all the usual advantages of decoupling systems (clarifying responsibilities, documentation, independent growth and optimization, interoperability with other programs, easier testing) if you are forced to define a clear interface between the two?

It certainly seems like specifying a build process and performing a build process are two distinct things.

They are different stages of the build, yes (although in a hermetic system you could in theory run the build process in parallel with the configure step for different targets). The challenge is integration. Things are much simpler when you ship the two programs together since they need to be compatible in terms of folder structures etc. It is also nice to keep things in memory sometimes. In other words, I think they should be different modules of one build system, rather than completely different programs.

To your point, integration will allow the two to be iterated upon faster, since changes can be more easily released together.

Better integrate may be, but not merge into one. Since super optimized build systems also increase complexity of their usage. So the idea is to have user friendly front end, which produces complex input for very fast backend.

Ninja view their build idea as "assembly like". While assembly surely allows you producing very fast results, it's not easy to use at all, if you are using it directly.

> Since super optimized build systems also increase complexity of their usage.

That's not correct. Complexity arises from the inability of expressing what you want and lack of abstractions over platform details.

Ninja for instance is to primitive to be productive and does not have any understanding of C++.

Buildsystems like buck allow you to express things in a declarative manner eg.:

    cxx_library(
      name = 'foo',
      srcs = glob(['src/**/*.c']),
      exported_headers = glob(['*.h'])
    )

    cxx_binary(
      name = 'app',
      srcs = ['main.c'],
      deps = [':foo', ':bar']
    )

buck implements sophisticated (disk & network) caching, optimization and scheduling strategies to make things fast.

Furthermore it will use services like watchman (if available) to precompute what things need building if you change some files for fast incremental builds.

Lastly it will strip and sort symbols in your binary to make sure the hash of your binary is always the same for the same set of inputs.

All this complexity is handled for you and all you need to do to run your executable is

    buck run :app

Ninja is by design low level, it doesn't need to know that about C++. That's the point of having a front end that would know about libraries and such.

So not sure what you argument is about. It's like saying that assembly has no high end abstractions. Sure, it doesn't. It in itself is not an argument against splitting the build into several passes.

That said, Buck looks like an interesting build system.

In general, to have proper handling of librarires and etc. the language itself should support the notion of modules, like Rust does. Then you can implement sane tools (cargo). C++ is still crippled in this regard. Though there are some ideas how to improve it:

https://medium.com/@dmitrygz/brief-article-on-c-modules-f582...