Date: Mon, 23 Jun 1997 19:52:22 +0300 (IDT) From: Eli Zaretskii To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com Subject: Re: Library rebuilds In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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. > 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 {} ';' If every Makefile includes this (as well as anything to be done in the current dir), and assuming `make_in' is a batch file or a shell script that chdirs to its argument and runs Make there, won't this do the magic you are after? > 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. The docs for latest versions of GNU Autoconf include some guidelines on portable usage of standard Unix commands. I think if you only use what they say, you won't have portability problems, and since DJGPP ports are all GNU stuff, they support that minimum. > 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. I think you will have hard time if you ignore simple utilities like `cat' and `mv'. > *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.