Mail Archives: djgpp-workers/1997/06/23/06:28:37
Hello, DJ, and the gang.
On Fri, 20 Jun 1997, Hans-Bernhard Broeker wrote:
> On Fri, 20 Jun 1997, DJ Delorie wrote:
>
> > > and so on. One point that bugged me most: I had to call 'makeall.bat'
> > > *four* times in a row to build the library from scratch (i.e. even the
> > > fourth compile still found a reason to recompile something...).
On re-examination, that number is three, not four, actually.
> > I think there's a dependency loop, so no matter how many times
> > you makeall, something gets made:
> >
> > stub.h depends on djasm.exe
> > djasm.exe depends on libc.a
> > libc.a depends on crt0.o
> > crt0.o depends on stub.h
Almost true, but it's stubinfo.h, not stub.h itself.
But, come to think of it, we wouldn't expect 'stub.h' or 'stubinfo.h' to
really change because we recompiled 'djasm.exe', would we? So this loop
can be cracked open by using 'update' instead of cp or copy to copy a
second build of stubinfo.h over the first one (and a timestamp file for
make to keep track of things).
> > As for reorganizing the build, I'll accept changes provided the solve
> > the following needs:
> [...]
> You know what? I'll try that, this weekend.
Here's a description of what I've got until now:
* It does build wherever you choose to unzip it. Just be sure
DJDIR is set.
* It doesn't install everything right into the DJGPP tree immediately
(too dangerous, IMHO). A 'make install' target is planned for that.
* native build (i.e. with DJGPP itself for all compilations) is one 'make'
now, and there's almost no .bat file left. Some targets aren't built yet
(debuggers), but shouldn't pose any additional problems.
* Some of the preparations for cross compilation are done. You can specify
one CC for the initial build of some of the more necessary tools, like
djasm, stubify and update, another one for the libraries themselves, and
possibly even yet another one for the 'final' build of the utilities (Just
imagine you want to build a Linux-to-DJGPP cross compiler on a DEC
Alpha..., given Alpha-hosted compilers targetting Alpha, Linux and DJGPP).
Doesn't quite work yet, but the hooks are there.
* The cross-compilation changes solved some of the circular dependency
problems in passing. By having two independent
* I've started looking at the (2.00) Linux-to-DJGPP cross compiler package
for some possible tricks. That package already does build in one 'make',
but it turns out to have other minor problems left to be solved, some of
which I stumbled upon in my own effort as well.
* I try to do everything I can with make itself. It's the only really
portable method I can think of that does not require many external tools
to be installed. If make had 'for' loops, there'd be almost no need for
platform-dependency left in Makefiles.
* Currently only the 'src' directory found in djlsr201.zip is
considered. I didn't even look at the other ones. All files built
by calling make from the 'src' directory are put below there.
Problems encountered so far:
- 'rmake.cc' and 'update.c' won't build without major modifications on
anything but DJGPP or at least DOS itself (glob(".../filename") in rmake,
_open() and friends in update). I've changed update a bit (#ifndef
__DJGPP__ protected) so it will compile and work on Linux, and replaced
'rmake' by a shell script (along the lines of 'make.sh' found in the
djlsr/utils directory). Could we require bash, findutils and sed for
rebuilding the lib on DOS? I don't think so, esp. for bash.
- dxegen is necessary for the library build, but won't (yet) build on
anything but (cross-)DJGPP. This will need some rethinking of strategy, it
seems.
- I don't think there's any *really* portable way to use recursive makes
on both DJGPP and whatever Unix-alike you choose, without insisting on the
presence of GNU make. At least none that I know. So GNU make will
probably have to be required, for 'make -C directory' and text
transformation functions (wildcard(), and friends) to work.
- The make variable GCC is reset from scratch in some of the subtrees,
instead of keeping at least some of its parts. This causes major headaches
at places. On cross compilation, you keep getting errors because the name
of the compiler, and some of the CFLAGS are hardwired in about half a
dozen different places, so a change in the central place doesn't affect
the sub-makes.
- Compilers other than DJGPP itself don't understand the @gcc.opt method.
Currently, I use `cat gcc.opt` instead on Linux, but that'll have to be
replaced by internal techniques of make. gcc.opt will probably go
away completely.
- I'm still not sure how to detect if another make run might be necessary.
Could 'make -q' do the trick?
So, just in case someone has some really cool ideas to solve these, or
tips which pitfalls I should avoid, feel free to tell me.
HBB
broeker AT physik DOT rwth-aachen DOT de
- Raw text -