Date: Mon, 23 Jun 1997 19:08:45 +0200 (MET DST) From: Hans-Bernhard Broeker Subject: Re: Library rebuilds In-reply-to: To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com, dj AT delorie DOT com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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