Hi Domen, On 02.12.2017 15:58, Domen Vrankar wrote:
Stefan I have one suggestion - maybe a stupid one but that's for you to decide...
Since Faber is meant to be a cross platform build system and CMake is a build system generator you could perhaps start by competing with other build systems by attempting to integrate Faber into CMake as yet another build system along side Makefiles, Ninja...
What would be the point of that ? Do CMake users really care what build system "backend" is being used ? I thought the goal was for them to only interact with CMake itself ? I expect Faber to get most publicity from its simple and portable interface, which wouldn't even be visible if it were used as a CMake backend. Moreover, CMake as a build script generator produces extremely ugly and unreadable Makefiles. That's in the nature of the approach of a macro-language. The Makefile has degenerated into an intermediate representation, not something for a human eye to dwell on. Doing that with Faber would be entirely pointless, I think. Though I may misunderstand either what you are suggesting, or even the way(s) in which users use CMake.
C++ evolved on top of C, CMake evolved on top of existing build systems so I don't find it a bad idea to hitch a ride on CMake with Faber and improve them both by doing that.
Not everyone agrees that it was to C++'s advantage that it was (initially) promoted as "C with objects". But let's not digress. I'm (obviously) not against the idea of layering new frontends over Faber. In fact, I have designed it to be usable as a library, precisely so people can extend Faber with frontends (for example graphical ones). But I think I'd spend my time more wisely focusing on Faber itself, its missing features, documentation, etc., and let those who like working with CMake add and improve bindings to build system backends. Stefan -- ...ich hab' noch einen Koffer in Berlin...