Hey,
On 10 August 2012 10:48, Ciprian Dorin Craciun
<ciprian.craciun_AT_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
Received on Fri Aug 10 2012 - 12:35:05 CEST