Build system hunger

So the past week(s) I've been revisiting the tools architecture in my engine. Some of the tools have ended up getting both a visual makeover as well as fundamental changes under the hood. Part of my tooling that care of asset compilation and verification has gone through several of those iterations.

https://www.dropbox.com/s/qzq7cn705hepnae/cli-interface.PNG?dl=0

But the last week in particular I've been looking into build systems and embedding python after having gotten wind of  google's bazel. My first impression of bazel is that it is quite elegant in the way builds are described declaratively, as well as the technology coined behind it. Incidentally, they seems to have opted for a similar strategy as my own asset management system. Both systems employ services that uses a database to store associated meta-data. And it uses the meta-data to ensure the smallest/fastest build. Now of course while I don't have several terabytes of art data to process, my small scaled pipeline doesn't showcase its full potential, however being able to decouple all art processing logic outside of the engine where it's less critical has already been a joy to work with. And now slowly bit-by-bit I’m revisiting the tools and upgrading them from prototypes into something hopefully more lasting.

https://www.dropbox.com/s/fi28aga2byx90op/resourcebench_2.png?dl=0

One of the things i've been really looking into are build systems themselves, I have already started to look into systems like SCons, waf, cmake, premake, jam, make, ninja, bjam. And compared to the elegance that bazel seems to offer, in my opinion, the alternatives leaves full to be desired.  So far I think premake has been one of the closest fits to what i value most, something simple but also keeping my workspace central. However one of the thing that bothers me with premake is that it incorrectly assumes the platform i..e. vs2008, 2010, gmake is an either all or nothing operation. All your projects get generated using the same platform, but parts of my code are in 2008, and parts are in 2012, and parts in 2015. This sort of arrangement isn't even posible to do with premake.

While lua is a nice language, small and compact, in general build tools are better represented with in a language that can support the diverse nature of build tools, and has a less oddities associated with it, 1-based arrays? No thank you I’ll pass that up. Python is really a great a alternative, especially as we can it in bazels landscape. So one of the things i'm currently doing is designing a premake alternative based on python, here are the preliminaries:

https://gist.github.com/phr34k/564535c16b35e0c24780