Date:	Mon, 23 Jun 1997 19:08:45 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Subject:	Re: Library rebuilds
In-reply-to:	<Pine.SUN.3.91.970623193133.7182A-100000@is>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com, dj AT delorie DOT com
Message-id:	<Pine.LNX.3.91.970623185442.31017F-100000@acp3bf>
MIME-version:	1.0

On Mon, 23 Jun 1997, Eli Zaretskii wrote:
> On Mon, 23 Jun 1997, Hans-Bernhard Broeker wrote:
> > I was a bit hesitant to do that because DJ had mailed me before, requiring
> > among other things: '4. Depends only on djgpp.' I simply wouldn't say that
> > Bash is already a 'part of djgpp'. Not yet. 
> 
> I think you can safely say that now, since so many packages need it to 
> build them.  However, since DJ is the one who builds libc, it's his 
> decision whether to depend on Bash and other utilities.

Or more precisely, what exactly he meant by saying 'only djgpp'. DJ?

> > What I actually wanted to have was the effect of 'rmake.exe' (i.e. find
> > all makefiles in subdirectories of the current one, make them, collect the
> > .o file lists and build a library from them), but implemented by makefiles
> > only. 
> 
> How about using `find'?  Something like so (untested!):
> 
> all: force
> 	find . -type d -depth -prune -exec make_in {} ';'

Of course, that's exactly what the script implementation of rmake does, in
a nutshell (and DJ's (?) make.sh as well). But that means I have to assume
the user of my Makefiles has find installed, which, so far, I hesitated to
do, on the same grounds I didn't use Bash. 

> > Well, I tried to not use more of the optional packages and ports than
> > necessary. That even includes fileutils, ...

> I think you will have hard time if you ignore simple utilities like `cat' 
> and `mv'.

Yep. So let's see what the current implementation would need (or better,
the one that's in my head, but not in actual code yet, based on today's
disussions), in addition to the 'core DJGPP development system', and the
lib sources themselves: 

Make, Bash, Find, Sed, Fileutils, Textutils (for cat)

This list already quite long, and we're not finished yet.

> > *Ideally*, not at all. But there might be really obscure cases (like, say,
> > radical changes to the whole file handling stuff in the library, or a new
> > object file format), that might actually affect the results of running,
> > djasm and friends.
> 
> These cases should require exactly two runs.  It's like building gcc on a 
> machine with only a native compiler: you build once with cc, then another 
> time with gcc.

... and a third time to be sure you got it right (like in 'make compare').

Hey, maybe that's what I should do... install even 'libc.a' using
'update', and then let make call itself until it libc.a stops to change,
and only then allow 'make install'. But I'm slowly loosing my footing
here, I think :-)

HBB

- Raw text -