Mail Archives: djgpp-workers/1997/06/24/06:49:30
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
- Raw text -