Date: Mon, 23 Jun 1997 12:25:14 +0200 (MET DST) From: Hans-Bernhard Broeker Subject: Re: Library rebuilds In-reply-to: To: DJ Delorie , djgpp-workers AT delorie DOT com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk 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