Date: Mon, 24 Nov 1997 02:48:56 +0100 (MET) From: Hans-Bernhard Broeker To: DJ Delorie cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com Subject: Re: alpha-971114: Makefiles revisited In-Reply-To: <199711240132.UAA16504@delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 23 Nov 1997, DJ Delorie wrote: [This will be the last answer from me for now. It's 02:30h in the morning here, gotta get some sleep :-)] > Well, yes. I meant everything that *should* be built with the new > libc should be built with the as-yet-uninstalled one. The current off-$(DJDIR) solution already grants this, I think. At least, the "ident | grep '$Id' | sort | uniq -c" output says it does. > > * 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. I don't think it's used in the build process (that's what 'stub2inc' is used for, IIRC). But it's a handy tool for the users, so I think it should go into djdev*.zip. > > * A .txh bug noticed in passing: 'remque.txh' has 'putenv' as the > > function name in the syntax section (fixed) > > Fixed where? In the version I have sitting on my machine at home. The patch will be in the next set of diffs I'll send, promised. > > * 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. Even easier: just 'make clean' after the build, and they'll be deleted, so the packaging routine will not be able to package them any more :-) (But yes, you will get that list, ASAP) > > MY_LIBGCC_A = $(shell $(CROSS_GCC) -print-libgcc-file-name) [doesn't work ...] > > Any ideas how to get around that? > You'd have to change gcc to use forward slashes exclusively. That's about as far as inspecting gcc.c took me, yes. But doing that (it's a compile time option only) would render it less usable for many other, more important tasks, of course. And I cannot count on everyone having a gcc.exe changed this way, anyway. > > * 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. I had something working in the July version of the makefiles. It was a copy of the .o->.a file machinery, essentially. The same could be done again, of course, in makemake.c. BTW: congratulations to the idea with misc.c. Seeing it immediately made me think "Yes, that's the method! What a pity you didn't imagine that one." :-) Bye, for today. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.