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

[Fabian Groffen]

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?  How long
does it take to build just *all* of them?

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


-- 
Fabian Groffen
Gentoo on a different level