[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [patch] faster Makefile.in -> Makefile translation
From:       Michael Matz <matz () ifh ! de>
Date:       2000-04-03 14:14:54
[Download RAW message or body]


Hi, (beware: reply to three messages)

1)
On Mon, 3 Apr 2000, David Faure wrote:
> On Mon, Apr 03, 2000 at 11:08:47AM +0200, Michael Matz wrote:
> > > Actually, I wouldn't mind seeing support for this dropped either.  
> > > Perhaps by default configure could create a subdir "obj" to stick
> > > all of the object files in?  This means that to solve any weird
> > > dependency or build problems, one could just rm -rf obj, and rerun
> > > configure et. al.
> > 
> > I fully agree.
> 
> I don't. Up to now the developer had the choice, why remove this choice ?
> For instance when making source packages from a check'ed out tree,
> I'm happy that my objdir is not inside the source dir (I put them
> somewhere else). And it's confusing for most people, who are used
> to srcdir==objdir. We could set up instructions on how to use scrdir!=objdir
> since, I agree, it's good practice, but enforcing it is a very bad idea.

OK, OK :) , with "fully" agree I ment the part "I woudn't mind seeing
support for this dropped". Hmm... not really full ;)

May be, we could pop up a fat message annoying the user until he does
srcdir!=blddir ;)


2)
On Mon, 3 Apr 2000, David Faure wrote:
> On Mon, Apr 03, 2000 at 10:59:48AM +0200, Michael Matz wrote:
> > On Sun, 2 Apr 2000, Stephan Kulow wrote:
> > > Well, David's idea was to patch config.status after the act. I don't
> > > know how useful this is, but you could use perl for that too ... ;)
> > 
> > I have a script which does exactly that ;) 
> Great ! :)

It's attached. (read on)

> > Or we can (after @autoconf in Makefile.common) patch configure to do the
> > right thing. Man, what hack ;) So we would patch a file, to run a file
> > which patches another file, which finaly patches many files. Uhh. ;)
> :-)))) LOL :)

Don't laugh. It's now this way ;)


3)
On Mon, 3 Apr 2000, Stephan Kulow wrote:
> David Faure wrote:
> > On Mon, Apr 03, 2000 at 11:08:47AM +0200, Michael Matz wrote:
> > > But it's reasonable to see perl as a system tool, so we use this.
> > Definitely right. Binaries no, perl yes, with a fallback on standard sh.
> Well, we right now discuss on removing that fallback - or making it:
> patch the configure.in and run autoconf ;)

OK, the diff in the attachment is against fresh CVSup. It's kind of
all-singing-and-dancing, but ugly as ....

It now works the following way:
1) provides macro KDE_FAST_CONFIGURE (thereby --disable-fast-perl)
2) (1) is called from KDE_SET_PREFIX (so most configure.in.in's work)
3) Makefile.common patches configure, after it is created with a sed
   script (shudder), to conditionally (on with_fast_perl) patch the
   config.status it just created (yes, before running ;)
4) If by configure time --disable-fast-perl is given, nothing happens
   and normal autoconf behaviour is crawling, if it's not given,
   admin/conf.change.pl reads and processes config.status, throwing away
   autoconf sed horror and including fast fresh perl.
5) config.status does the main loop in admin/config.pl (which is now a
   little bit more robust, with respect to the given substitutions)

Note, that we don't have to include any GPL autoconf code anymore. The
parsing in conf.change.pl is of course sensitive to changes in
config.status (and so to changes in autoconf), but I hope it works at
least on the machines doing the snapshots. Try it and let me know.


Ciao,
Michael.

["mm-comm.diff.gz" (APPLICATION/x-gunzip)]

[prev in list] [next in list] [prev in thread] [next in thread]