Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

[Alfred M. Szmidt]

   ``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.