Hi, > | Somewhere early during ./configure, the host type is checked. If it > is | GNU (Hurd), an ordinary build is prepared. (Checking libs, using > | automake-generated makefile etc.) However, if it's Linux, the > behaviour | changes completely: All the ordinary checks are skipped; > instead of an | automake-generated makefile, a simple, hand-written > makefile is used, | with only a couple of configuration variables > substituted. > > Yes, you could make something like this work, but why skip the checks > on one system but not others? What happens if you configure your > software on a system that looks like "Linux" but doesn't actually have > all the features you expect? Wouldn't it make more sense to perform > all the same feature tests on every system? Well, in this case: No :-) If the kernel is Linux, that's all we need to know. I guess there would be less confusion if I had explained what I actually want to achieve from the beginning: The project at hand (KGI), only on the Hurd (for now) is built as an ordinary standalone program. On monolithic kernels (Linux for now, with FreeBSD and maybe others to follow later) however, it is a kernel component, and built by integrating it into the kernel source tree. That's why the Hurd is the only system where we provide a real build environment. On other systems, the build environment is whatever is used to build the kernel, and we needn't bother about it. However, for developers' convinience, I want to still generate a (pseudo-)makefile inside the KGI tree on those other systems. It will prepare the build by copying the KGI files over to the kernel source tree (given as an option to configure), and optionally kick off the kernel build by starting a user-supplied script (another option to configure). Also, I want to implement a dist target, which creates a kernel patch for distribution, so ordinary users don't have to bother with any specific build system -- just apply patch and build kernel as usual. I hope this clears up the issues a bit... -Olaf- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
