Date: Mon, 23 Jun 1997 17:05: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 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 try to do everything I can with make itself. It's the only really > > portable method I can think of that does not require many external tools > > to be installed. If make had 'for' loops, there'd be almost no need for > > platform-dependency left in Makefiles. > > Since there is a (very good) port of Bash, and Text-/File-/Sh-utils are > also available, you can relax here, I guess, and use them whenever you > need. 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. > You can replace `update' with a shell command that calls `cmp' for Unix > platforms. Some GNU distributions include a script called > `move-if-changed' (sp?); I think GCC is one such distribution (probably > the original reason for writing `update', right, DJ?). I thought of something like that as well. But one plan I had was to minimize the number of 'ifeq ($(DJGPP),)' conditions all around the Makefiles. So I patched update.c to compile on Linux, and compiled it into 'hostbin/update.exe', i.e. exactly the same name as the DOS version. This might even help in providing DJ's utilities, including update, for cross-DJGPP's as well. > > djlsr/utils directory). Could we require bash, findutils and sed for > > rebuilding the lib on DOS? I don't think so, esp. for bash. > > We already have Bash. It shouldn't be a problem to require it for > building the library if it cannot be avoided (all the latest ports of GNU > stuff are done using Bash and friends). But if you can avoid it, please > do. Well, it'd sure be a lot easier to get it machine-independant by using Bash, but not everyone using DJGPP necessarily has Bash as well. Anyway, if there's no serious objection, I think I will change to Bash. > > - I don't think there's any *really* portable way to use recursive makes > > on both DJGPP and whatever Unix-alike you choose, without insisting on the > > presence of GNU make. > > Can you elaborate why is this a problem? The current DJGPP port of Make > doesn't have any problems with recursive invocation, even without -C. I I'm not sure how to describe it. I've not gathered all that much experience with DJGPP Bash yet, esp. not with the more tricky options, like SYSROOT (or whatever it's called). 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. And that seems to be rather hard, if not impossible. You need external utilities, which is where the portability issue jumps into the story: without requiring a 'maximum Unix portability toolset' on DOS, all external command invocations except 'gcc' itself must be considered at least potentially unportable. > > - Compilers other than DJGPP itself don't understand the @gcc.opt method. > > Currently, I use `cat gcc.opt` instead on Linux, but that'll have to be > > replaced by internal techniques of make. gcc.opt will probably go > > away completely. > > How about $(shell) ? The latest DJGPP port of Make can run arbitrary > shell commands there, so you can say $(shell cat gcc.opt) or some such > and have it work on Unix and MSDOS alike. (Except that $(shell) is > probably GNU Make-specific.) Well, I tried to not use more of the optional packages and ports than necessary. That even includes fileutils, so I did not want to assume existence of a 'cat' command on DOS. And this is only one of them. But you're probably right in saying that I should just use everything that's available, provided it's sufficiently stable. (Hey, for something like 5 seconds I even thought: "Why not use autoconf for this?" :-) > > - I'm still not sure how to detect if another make run might be necessary. > > Could 'make -q' do the trick? > Ideally, a single run should do everything. If this is true, why do you > need -q? *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. But then, 'make -q' (-q is the "query: something to be done?" flag of make, or at least that's the one I was thinking of) wouldn't detect that, anyway. So DJ's first requirement he mailed '1. Build everything from scratch in one command' may actually be hard, or even impossible to do in every case. But for normal situations, I have checkmarked that requirement as 'for native builds: done' in my notes. HBB