On Thursday 23 June 2005 20:04, John Skaller wrote: [...] > That cannot be allowed, the build must proceed without > ever installing anything: if you really need something > installed you will need to provide a separate package, > and then the build interaction cannot be cyclic.
Ung. The build scripts do assume that as they build things, those things become available to use. For example, in order to build the libraries for each target architecture, they use the code generator and librarian tool that they've just built... I suspect that the only way to cleanly package this for Debian (and for most other architectures) would be to split it up into (a) tools, (b) code generators, (c) compilers, (d) libraries. Each one would be a different Debian package and build and install seperately (but possibly from the same source package). This does mean that building it all in one pass would be tricky, though. > Otherwise, if you have a cyclic process in the build, > then there is no alternative than to provide an initial > value for it, hopefully one such that the recursion > fixes fairly quickly .. How about this: supply a prebuilt parser; llgen builds using this parser, and then uses itself to generate a new parser. The build will then *fail* if this new parser does not match the prebuilt one. While this doesn't get around the bootstrap problem, it will eliminate gotchas due to the pregenerated file being out of sync. > BTW: is this vbccz you're talking about? No, this is the ACK, the toolchain that was written for Minix. It's been open sourced and, despite having timestamps over twenty years old, still works rather well --- if you can get it to build. http://tack.sourceforge.net -- "Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm Jim (evil) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
