Date: Sun, 23 Nov 1997 20:32:58 -0500 (EST)
Message-Id: <199711240132.UAA16504@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: broeker AT physik DOT rwth-aachen DOT de
CC: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-reply-to: <Pine.LNX.3.93.971124021725.23046B-100000@acp3b9> (message from
	Hans-Bernhard Broeker on Mon, 24 Nov 1997 02:29:22 +0100 (MET))
Subject: Re: alpha-971114: Makefiles revisited
Precedence: bulk


> > As long as everything gets built with the as-yet-uninstalled libc and
> > not the previously-installed libc.
> 
> (Except for the $(HOSTBIN) ones, that is, right?)

Well, yes.  I meant everything that *should* be built with the new
libc should be built with the as-yet-uninstalled one.

>   * bin2h is in the sources, but doesn't seem to be in djdev, why?

I don't know why.  Perhaps it isn't used by anything, so I thought it
was built just for doing the build itself.

>     (gxx.exe isn't in djdev, either, but I guess that's because it
>     is to be included in gpp*b.zip, right?)

No, that's a mistake.

>   * A .txh bug noticed in passing: 'remque.txh' has 'putenv' as the
>     function name in the syntax section  (fixed)

Fixed where?

>   * The current lsr dist contains some non-source files, and at least 
>     one temporary file (djasm-n.c, built from djasm.y). 

Please identify them and I'll add the exclusion to my packaging
routines.

>   * I tried to use 'gcc -print-libgcc-file-name' to auto-set
>     '$(MY_LIBGCC_A)' for native builds. But gcc prints something like
>     'c:/djgpp/lib\libgpp.a' (note the '\'). The backslash in
>     this string gets eaten up when I write the makefile line like this:
> 
>     MY_LIBGCC_A = $(shell $(CROSS_GCC) -print-libgcc-file-name)
>  
>     Any ideas how to get around that?

You'd have to change gcc to use forward slashes exclusively.

>   * Currently, 'libc2.tex' is rebuilt every time 'make' is run. Not a
>     big issue, but a fixable one.

Hard to get right, since make can't detect that a target no longer
depends on a file that's been deleted.  That's why libc's dependencies
are so complicated - it needs to detect the case where an object was
removed, even when all remaining objects are older than the library.