``Adding the proper libraries to HURDLIBS'' is basically the first sugestion, combined with a reliable mechanism to make sure that discrepancies will always be noticed (and do not lead to at first incomprehensible--like in the example I gave--or--maybe even more dangerous--silent breakage). This could be implemented by checking each generated dependency file about not including any files from `/.*include/hurd/'.
I'm not sure that this can be done in an automatic way without fiddling with -nostdinc and -nostdlib, and adding all libraries/include directories manually. I think that the current setup is good, and works well, sometimes there are bugs (like in your case), but these can be easily fixed. Infact, this isn't a bug in HURDLIBS, but in configure.in not doing the proper checks for the API which is used (it was an API issue right?). It is configure's job to notice these kind of incompatibilities. We just have been quite lazy in this regard... Solution two is splitting the Hurd `collecting box' into a lot of smaller, independent packages. There would be a package `libihash', which is configured, built and installed into /lib/ and /include/ and then the packages that depend on libihash's functionality can be configured and built, using the libihash that was previously installed into /lib/ and /include/. Etc. I'm still not entierly sure what you mean, this is how things work right now... Only that translators in the Hurd use the libraries/includes that the Hurd has and not the system wide ones. If tehy don't, then it is a bug. Where will be the boundary for inclusion vs. refusal of inclusion? If there is a userbase for the translator/library, and there are people who wish to maintain it in the developer base of the Hurd, then it should be included (if the person who wrote the program wishes to have it included). This really is no different than including/excluding architectures in say libc or gcc. We have already a `ports' like setup for translators which are not part of the Hurd, i.e. HurdExtras, where people can maintain their own translators in a central repository so that it is easier to find them. Are you suggesting that things should be splitup so that each directory (i.e. module) has a configure file? This would be more of a headache than a benefit. I think that the current setup is really a good one, it has some flaws, like you noticed when you have incorrect dependencies, but I don't think that there are any problems that are so serious that it warrants a total rewamp of the build system. Our energies could be spent on fixing more important things. _______________________________________________ Bug-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-hurd
