[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] echo -n is not portable and used too much

From: Daniel Berlin <dan_at_dberlin.org>
Date: 2002-02-12 22:48:39 CET

> > 2) Makefile.in: Rebuild Makefile from Makefile.in using config.status
> > automatically.
>
> <rant mode="extreme">
>
> Absolutely not. No way. Over my dead body.
>
> This is one of the most borken behaviors ever given to the world by that
> bastard system, Automake. If your Makefile is out of date, then you can
> manually run the config.status script.
>
> <rant-story>
>
> (one day, long long ago)
> $ cvs -z6 up
> U ./configure.in
>
> (oh! a new configure. let me clean out the crap to start from scratch)
> $ make extraclean
>
> (fuckin' automake runs "automake" then "autoconf" then "./configure")
> ^C ^C ^C !!!!
>
> </rant-story>
>
> There is no way that SVN's Makefile will ever run auto-rebuild operations
> like that. Strict layers here. autogen.sh -> configure -> make. That order
> *never* goes the other direction.
>
> </rant>

Hey, we share a pet peeve.

KDE does this stupid behavior.
Of course, since it does it separately for each subdirectory, it's
amazingly time consuming. Normally, you see, they have some edits that
fast create the Makefiles. But that only happens in the configure script,
so when it decides to remake the stupid makefiles one at a time, subdir by
subdir, ...

I *hate* it when people introduce more broken behavior to fix broken
behavior.

Me:Why do we do <insert bogus thing here>?
Someone else (pretending this is justification, rather than
bozoification): Oh, that's cause automake is a pile of shit.
Me:<Sound of veins popping>

Don't get me started on libtool (aka 'Hey, let's write a complex library
dependency processing application, which needs to be using graph
algorithms, in a huge shell script that actually travels backwards
in time because it's moving so slow")
--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.