Mail Archives: djgpp-workers/1997/11/23/20:49:07
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.
- Raw text -