Re: [gentoo-alt] [prefix] gnulib (required for java on aix)

[Michael Haubenwallner]

On Thu, 2008-07-31 at 11:45 +0200, Fabian Groffen wrote:
> On 31-07-2008 11:29:39 +0200, Michael Haubenwallner wrote:
> > > I initially had in mind sort of the same, but with the cache in the back
> > > of my head.  Given that you require getopt some and other, you just need
> > > to get those .o files in a libgnu.a.  I don't think a .a file with more
> > > than you need is a problem (the linker extracts only what it needs, I
> > > guess), which means one can simply create the archive of all .o files
> > > available.  If we'd just have a directory somewhere, where Portage dumps
> > > the .o files to, creating the gnulib.a would be trivial, and the cache
> > > would be there immediately.  Given that it's probably a zipf
> > > distribution, the cache would be highly beneficial right from the start,
> > > so why not just do it that way?
> >
> > It's not that easy: gnulib .o files have dependencies on others.
> > Additionally there are some headers, which must match the objects when
> > used. And some of these headers hide system headers, or do #include_next
> > on them, with some wrappers #defined.
> >
> > (defining term "libgnu" to "libgnu.a and the headers" here)
> >
> > We could recreate the cached "libgnu" from scratch each time a package
> > requires another gnulib module not in the cache yet.
> > But I'm afraid this breaks already-installed packages when remerged, as
> > their configure might find another gnulib module available then, while
> > they could still work without it.
> > The difference to the non-cached libgnu out of gnulib.ebuild compared to
> > a cached one is that such problems are reproducible using the non-cached
> > one.
> >
> > This having said, I don't like one single growing _cached_ libgnu.
> > Instead I'd cache one libgnu for each used set of gnulib-modules.
> > This cache is pruned when reinstalling dev-libs/gnulib.
> >
> > This would result in something like
> >         /usr/lib/gnulib/getopt-strcasestr-xvasprintf/{include,lib}/
> >         /usr/lib/gnulib/another-getopt-strcasestr-xvasprintf-yetanother/{include,lib}/
>
> Why don't we just make sets of commonly used functions then?

Eventually we should look first which modules are required among several
packages, and add them to the current gnulib.ebuild, which defines the
initial set. Then lets see if we really need another set.

>   How long does it take to build just *all* of them?

That does not work. I've tried initially to pass $(gnulib-tool --list),
but there must be some bugs in the module-definitions, so that
--create-testdir does not work with them.

I'd like to look into fixing them only when they actually are required -
there are >900 gnulib modules defined ATM.

>
> > Or we go with the libgnu from gnulib.ebuild as done currently, and have
> > this being the growing one, but easier to control.
> >
> > Btw, seems the solaris patch for portage-utils can be reduced from >20k
> > to ~3k using gnulib.
>
> The largest part of the patch is in the format specifiers, which are not
> necessary if you allow warnings.

When using GNU getopt, these warnings go away on solaris ;)

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level