delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/11/21/21:06:18

Date: Sat, 22 Nov 1997 03:06:05 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: alpha-971114: Makefiles revisited
In-Reply-To: <199711220131.UAA18359@delorie.com>
Message-ID: <Pine.LNX.3.93.971122023247.10934E-100000@acp3bf>
MIME-Version: 1.0

On Fri, 21 Nov 1997, DJ Delorie wrote:

[as to not up to date binaries being distributed]
> > For example, here's the souped up result of an 'ident' run over the
> > current distribution of djdev202: 
> 
> Ick.  Must be utils and things that don't have dependencies on libc.

Seems so, if you mean 'no dependencies' as: their makefile entries don't
say that they depend on libc and the stub. That's part of what I fixed,
sometimes indirectly by giving an *.o file target, and letting generic
rules from makefile.inc do the rest, instead of naming the .exe's as
target directly. 

IMHO, all DJGPP-compiled .exe's in one distributed version of djdev should
be built in one single go, and they should all use exactly the same builds
of libs and stub.

[as to the make.exe transfer buffer size problem I had]
> > It's the commands that build 'makefile.oh' that causes the problem.
> > It tries to pass $(OBJS) to 'misc.exe echo makefile.oh'.
> 
> Those shouldn't be problems, since they only operate on one directory
> at a time, not on the entire set of objects.

In the subdirectories: yes. But the very same rule is also used in
src/libc, and there, $(OBJS) is 14KB worth of filenames, so make bombs out
trying to pass this argument list to misc.exe with only 16 KB of transfer
buffer available.

And src/libc/makefile.oh seems to be needed, after all, as the build
stopped because of problems with funny-named files like
	makefile.oh/ansi/assert/assert.o

(where obviously the \& has been substituted by makefile.oh, instead of
$(TOP), erroneously). 

[...]
> > just because I want to do it outside the main $DJDIR location. And the fix
> > is rather small: just an additional -I$(DJDIR)/include, after -I../include
[...]
> I can add that -I$(DJDIR)/include, but there aren't *that* many includes!

Correct. IIRC, less than half a dozen of them are actually used.

Actualy, my original (unreleased) approach back in the times of DJGPP 2.00
was to have a 'prepare.bat' file that copied these few files from
$(DJDIR)/include to ../include, and be done with it. But that would give
us yet another list of files to maintain, i.e. it'd better be avoided.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019