Date:	Fri, 21 Nov 1997 20:31:22 -0500 (EST)
Message-Id:	<199711220131.UAA18359@delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	broeker AT physik DOT rwth-aachen DOT de
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<Pine.LNX.3.93.971122005111.10934D-100000@acp3bf> (message from
	Hans-Bernhard Broeker on Sat, 22 Nov 1997 01:44:15 +0100 (MET))
Subject:	Re: alpha-971114: Makefiles revisited

> No, I was talking about a native build, and about the binaries that
> get build in {srcdir}/../bin, i.e. the final ones.
> 
> 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.

> Ooops, I was barking up the wrong tree, somewhat. The problem didn't
> really occur for the 'ar' command line, it seems (or so my lossy
> memory tells me, looking at the makefiles again, here at the uni).
> 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.

> You have to have them installed somewhere, yes, but I don't quite see why
> I should be forced to install a *second* copy of them for a native build,
> 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
> in the compiler flags. It won't make any difference when ..  actually is
> $(DJDIR), i.e. if the build is run inside the main tree. 

I can add that -I$(DJDIR)/include, but there aren't *that* many includes!

- Raw text -