Hey, On 10 August 2012 10:48, Ciprian Dorin Craciun <ciprian.crac...@gmail.com> wrote: > As such -- if I get the "suckless" definition correctly (but see > the P.S.) -- such a tool is far from the original intent because it > does all sorts of things instead of doing exactly one correctly...
We were actually talking about this on IRC just yesterday, also in the context of ninja: 16:47 < cls> i've not looked at it much yet, but http://martine.github.com/ninja/ 16:48 < cls> supposedly very fast build system by stripping out unnecessary make(1) features (I suspect we both found it the same way.) 17:12 < cls> maybe you could separate it out, so the part that handles the dep graph is actually a totally different utility 17:14 < cls> so when you just run one build it spins of a process to read the depfile, and then says right, these things are [new], what do i need to do? 17:16 < cls> ls -R | stest -n Depfile | deps Depfile | sh > Just for the record I didn't yet find a tool that solves exactly > one of those concerns, but I did find `ninja` ( > http://martine.github.com/ninja ) to come closer to my vision, by > solving only (C) and (D), leaving (A) and (B) for frontends... > (Although I would have loved to only solve (C) which is the hardest > part, and leave the rest to other specific tools...) Ninja itself looks a little messy, too. 17:00 < nsz> it uses $ for line break.. 17:00 < nsz> it's not clear how you can add extra dependencies to a build 17:05 < nsz> i don't like how there are local variables in rule with special meanings 17:05 < nsz> command = .. 17:05 < nsz> description = .. These are quite easy to fix; we'd have to play around with the syntax and come up with our own. But I would definitely like a tool that solves (C) and only (C). (D) follows trivially. > P.S.: Everytime I hear "suckless" (or "pythonic", or > "the-java-way", or "the-unix-way", or "the-<<favorite tool / > language>>-way"), it makes me thing of a dogmatic priest chanting his > ritual... And most of the time I have the feeling that people use such > a phrase when they can't provide a coherent argument, either for or > against something, but they feel in their guts that they are right and > thus they must be heard... The same could be said of words like "elegant" or "beautiful". There is a certain quality to a program that we can perceive but not quite explain in words. We can hope to design some eloquent, concise code that solves the problem with a cunning assembly of pared-down data structures that seem obvious only in retrospect... Aesthetics are all about feelings in one's gut. From here on out it's stack allocation, Indian peafowl, and the Panthéon clock. Thanks, cls
