Rants and sorrow

Well, this is a hard article for me because this is in some way postmortem for dogebuild. But things are not that bad after all.

I have lost my fate in dogebuild as universal builder. The main reason: I’ve worked for a certain time with mass migration from gradle to yandex inner CMake-like tool. I’ve found that all gradle build configurations are small projects by themselves. That led to a lot of small troubles when I’ve tried to migrate them. And after that I’ve thought: Do I really want to create dogebuild as flexible as gradle to maintain build tool just with another language? What if my source of inspiration was not so good?

Maybe I am too old now, but I think now that maven in core concepts is better than gradle. Maven lacks flexibility, but strict way to build application is better. You shouldn’t use whatever code layout you have and then wrap it all with glue groovy code in build.gradle. That only leads to a lot of hacks when developers do not understand what happens and just trows a lot of code to the build script in hope of it will somehow work. In a couple of years of active development, no one would understand what big parts of that file does and why configuration was made this way but not another.

I’ve designed dogebuild as a universal build system for any use-case, but now I think there are two of them, and they are very different.

Quick and dirty use-case

I’ve used dogebuild for a couple of small projects with less than 10 build steps in make mode. See my CV build script for example. That was a way much verboser than Makefile, but as far as I use Makefiles not so often I’ve always forgotten its syntax or how to set a variable. So it works for me very well. To cover this use-case, I would like to extract make mode functionality to separate tool oak-build. I would like to build it without any plugin interfaces. Just a bunch of helper functions for different cases. Dogebuild flexibility and inevitable mess won’t be a major problem for small projects as it will be write-and-forget code. And in case of need to remember what the hell was written, python syntax should really simplify that comparing to make.

Medium and big projects use-case

For medium and big projects, the flexibility of dogebuild is much dangerous. I described in the first part of that post why I am disappointed in such an idea now, and why I think that maven will be a better source of inspiration. For that use-case, I would like to start from the beginning with more fast and modern language (I mean go-lang). The main idea would be: You don’t need any flexibility, build system must provide little or no configurable building blocks that connect to each other via standard interfaces. In that case, plugin system is crucial to project as far as there will be fewer ways to glue build steps together. Also, to avoid quick and dirty build files, a yaml syntax should be a good match. If it is improved maven then yaml is a good substitution for XML. That use-case will be cover with walnut-build.