On Sat, 2015-03-21 at 17:05 -0700, Bryce Harrington wrote:
I like how with cmake, I find myself naturally compartmentalizing tests, reusing other people's cmake recipes, and in general being a lot more organized in laying out my cmake logic.
They're all terrible. But which ever ONE is picked, blessed is the project with simple instructions that can train new people into the skill rather than face them with a daunting wall of repetitive and nonsensical codeons.
For example. Instruct all people to build all those extra build files in a separate directory. Less there be confusion between build system files in the repository and generated build system files outside of it.
It wasn't until I was instructed to build in this way that the building process could work for me.
I propose a good system would be an explicit system. If a file is in the repository it must be marked as a) ignored in bazaar, b) file not for delivery (e.g build files) or c) file for packaging. Anything else should raise an error in standard testing to better catch the new contributor unaware.
It would certainly increase the value of test running for me to cover packaging issues too.
Sure, python is a great scripting language, but one could argue if you need a full bore scripting language to build your software, you've got a more serious problem than choice of build systems...
One could argue that, but I would not think it fair to. Just because something is Turing complete doesn't make it overbearing. The nearness of the packaging language to an existing and useful language should not be a herald of concern but a cause to rejoice. So long as the interface is clearly well designed and a better design than any other language for the same task.
After all we should compare cmake's build dialect to waf's dialect and not bash vs python to avoid mistaken attribution of complexity.
Best Regards, Martin Owens