Re: module gethostname

[Dustin J. Mitchell]

On Wed, Sep 15, 2010 at 12:01 PM, Bruce Korb <address@hidden> wrote:
> So, let's start that discussion again:  let's make an installable
> gnulib that basically does all the configure tests for the current
> target and cover 99% of all configure runs.  If someone has
> a strange configuration with extra libraries et al., then it ought
> to be straight forward enough to have an alternate gnulib.pc
> file installed in an alternate PATH setup.  I do not see an obvious
> reason why the configure process should be so ridiculous.
>
> Or is that just me? ;)

There are good reasons to want very close control of which
compatibility functions are -- and are not -- included in the build of
a particular project.  Personally, I've seen *very* odd errors pop up
during gnulib upgrades in Amanda[1], and I'm glad that I control
exactly which version of gnulib ships with which version of Amanda, so
that I can solve these problems once and not have to worry about a
full compatibility matrix between Amanda and gnulib.

There are also good reasons to want a "libcompat" that makes every
platform provide roughly the same interfaces, removing compatibility
concerns entirely from the downstream projects.

Would it be possible to build libcompat as a separate project that
depends substantially on gnulib?  That is, it contains all gnulib
objects and exposes their declarations and implementations in an
ABI-compatible way?

I suspect that this is harder than it sounds - gnulib does a lot of
Funny Stuff with header files and whatnot - but it might be a good way
to satisfy both needs, and if there are corner cases that gnulib can
treat, but libcompat cannot, then projects requiring those corner
cases can just use gnulib directly.

Just an idea..

Dustin

[1] To be fair to gnulib, in most cases these were the result of
gray-area coding practices in Amanda, not bugs in gnulib.

-- 
Open Source Storage Engineer
http://www.zmanda.com