> From: Ralf Wildenhues <ralf.wildenh...@gmx.de> > Please consider > - using the right configure switches to enable > cross-compilation if that is an issue for you,
> Both issues are extensively discussed in the Autoconf > manual. I am aware of this. Unfortunately, some decisions are still made automatically, and need overriding. The number of build options available is less than the number of decisions being made. This is a major problem when buildstrapping and scratch building, where you need to know that a package will build on a target machine that does not yet exist, and the target machine has some configuration differences to the current build machine (In my case, the same architecture, but a modified operating system, for example, a different shell, a different awk tool, a different Native Language Support handler, etc, etc.). The autoconf tool may decide to use particular shell tools, or facilities to package build that will not exist on the target. This means that I have no way of knowing whether a package will rebuild on the target, because it did not build using the same facilities on the test host. This means that if I have to modify a package source, and it becomes broken on the target, I have no way of knowing whether the breakage is as a result of my modification, or whether the breakage was already there, and the package would not have built anyway, even before my modifications were made. If I had full control of the autoconf process, this would be a lot easier. At the moment, I am having to try and reverse engineer squillions and squillions of pages of autoconf generated junk, to try and track down build decisions, in the hope of creating an override. And to compound the problem, the junk is not in a central location, but within each package. So I make a modification on one set of build scripts for one package, and I have to start all over again to make the same modification on another set of build scripts. (I wish we had scripts in a central shared location, so modifying one script, is global.) It would be nice to have full control, of the build process without having to try and reverse engineer squillions of pages of generated junk (of which only some is actually relevant to my platform). Mark. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
