I do not know what is "the percentage system", but I doubt it can be so wonderful to make me forget about all the other unnecessary problems.
It may be justified to use cmake when it is really needed. But the cixl interpreter can be built by a five-line makefile.
I was regarding how it outputs progress indication, like
[ 16%] Building C object ...
[ 91%] Linking C executable ...
etc (many lines elided). Back on the slow machine I was using when I was very new to Linux, progress indication ("how soon can I stop freaking out about this maybe not working") was very nice to have :DBut (10 years on) I can understand it being icky to use. I guess, ugly as it is, it's a little more structured than automake is, and maybe that's its redeeming quality.
Maybe build systems are the dead-centre of a "sour spot" (opposite of sweet spot) in computer science, with no truly nice solutions out there? (Genuinely curious. The exponential profusion of JS build systems suggests it's rather hard to solve.)
The only explanation I have is that
- Maybe the author is used to cmake
- Maybe this project has Big Goals And Ventures™ syndrome - and, hence, all the enterprise build systems. (Hopefully not, it looks kinda nice)
I think it's the opposite. It is a very, very sweet spot for which many essentially perfect solutions exist. Then, it attracts all kinds of extreme bikeshedding and produces the monsters we see here and there.
What do you think are the best/"essentially perfect" solution(s)?
(Said as someone who just figured out his first Makefile a couple days ago :P)
I take it that cmake tried to tackle autotools, partially succeeded, and partly succumbed to autotools' all-devouring complexity? :)