Mail Archives: djgpp-workers/1997/06/23/11:06:36
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
- Raw text -