Re: link: "Recursive Make Considered Harmful"
-On [20050111 08:32], Christopher Vance (christopher@nu.org) wrote:
>On Tue, Jan 11, 2005 at 07:53:54AM +0100, Jeroen Ruigrok/asmodai wrote:
[scons]
>I fully agree.
Although I must say I like some of the things they are trying to address.
It feels a bit between a cross of autoconf with make.
>>I consider jam to be a step in the right direction.
>
>I'll consider that a recommendation to have to look into jam.
It's not by far the best tool (if such a holy grail even exists of course),
since it has some make like notations in it still ($(<) and $(>) to name but
two).
But I like the abstraction between the rules you create in your build files
and how you can keep the top level build files relatively clean.
Yes, you can do the same with make (take the bsd.prog.mk abstraction for
example), although it quickly becomes cluttered.
>But how much of this cleverness needs to be done by run-time
>calculation? Using a different *.mk file for different invocations
>isn't the naughty thing I was talking about, unless your makefile
>recurses using both of them at different times, or loops, or ...
Mmm. Depends on how you define run-time with a build tool. A build tool
will almost always (what else is its purpose if it doesn't) generate new
files from existing files.
You could of course split a build tool's execution in two phases, first a
dependency/target calculation phase, followed by the real build phase, which
doesn't need to do any fancy 'run-time calculations'.
>Agreed. Although I bemoan the amount of non-declarative stuff in the
>typical usage of make these days, because I don't think it's all
>justified, I would also feel quite straightjacketted if I couldn't use
>it when I thought it was justified.
Well, one of the things that bit me is the fact that you have to do weird
hacks to just get the toplevel dir assigned to a variable to make everything
relative.
>What would be nice is a way to do all the fancy stuff up front, and
>produce a declarative description of what needs to be done.
>Unfortunately, the easiest way to work out what make would do is to
>get make to do it.
>
>I don't like all the GNU autocrap stuff, which supposedly does some of
>what I want, at least partly because the resulting Makefiles are still
>not fully declarative.
Hmm, I don't like auto* much myself, and I have done way too much of that
for various programs.
I settled on a postfix-like shell script that tries to make educated guesses
about the system and its environment.
>[I guess it's like my attitude to C++ - it was a good language before
>it grew fat, and now people feel they have to use feature X, even
>though feature Y is cheaper both size- and time-wise, and can do the
>same things X was used for. A company I worked for rewrote some
>templated C++ into C. The resulting binary was only 1/10 the size,
>and far easier to maintain - the problem wasn't so much the tool as
>inappropriate usage of the bells and whistles.]
Digression: C++ in general is used wrongly by a large majority of its users,
true. Not sure how many of you get ACM's Queue magazine, but in the latest
issue there's an interview with Smalltalk's designer and how we describes
the state of languages is quite right. Instead of progressing on and on,
we're actually moving backwards with our appreciation and use of languages
like smalltalk (which he himself considers outdated by now).
Of all the languages I have used/learnt in recent years Python is the one
that impresses me the most in terms of how quickly you can get stuff working
without resorting to the mess that Perl in general seems to invite people to
make of it. I need to try Ruby more nowadays as well.
For C I envision (as part of the TenDRA work I am doing) that we need to
make a move towards compilation detection of typical programming constructs
that lead to problems.
--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Free Tibet! http://www.savetibet.org/ | http://ashemedai.deviantart.com/
http://www.tendra.org/ | http://www.in-nomine.org/
Nothing is ever as it appears. You fool only yourself if you believe
what is easiest to believe...
討論串 (同標題文章)
完整討論串 (本文為第 12 之 31 篇)：