Date: Tue, 24 Jun 1997 12:46:55 +0200 (MET DST) From: Hans-Bernhard Broeker Subject: Re: Library rebuilds In-reply-to: <199706232339.TAA26150@delorie.com> To: DJ Delorie Cc: 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, everyone. > > 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? > > I wouldn't be surprised if it did. We've done those kinds of > optimizations in the past, replacing 5-byte variants with 2-byte > variants for certain forms of some opcodes. Point taken, but changes like that are mostly accounted for already. Here's the build process for the stub, as I currently have it, expressed in form of make dependency rules, and leaving out all files unchanged by the compilation process: ('build-' prefix means these programs will be compiled and run on the build platform, not on the host or target). build-djasm build-stub2inc build-update: force stub/stub.h stub/stub.map: build-djasm build-stubify: stub/stub.h stub/stub.map(?) ../include/stubinfo.h: build-stub2inc stub/stub.h stub/stub.map ../lib/libc.a: ../include/stubinfo.h djasm stub2inc update {...}: ../lib/libc.a build-stubify That way, changes to, say, stub.asm would be accounted for in the one build of stub.h, and that's it. And changes to djasm.y will propagate on two separate paths starting with build-djasm, via stubify and via libc, that will join again when the 'final' utilities are build. That way, there's no circle anymore, as long as we can assume that the behaviour of djasm does not depend on wether it was compiled on the 'build' platform (using an 'old' DJGPP, e.g.) or on the 'host platform'. BTW, there is one GNU-dependency in djasm.y: at least on my Linux box, it refuses to build with the Berkeley yacc. You have to use Bison. I'll see if I can change that. HBB