| 1 |
On Thu, 2008-07-31 at 10:09 +0200, Fabian Groffen wrote: |
| 2 |
> On 31-07-2008 10:00:25 +0200, Michael Haubenwallner wrote: |
| 3 |
> > Thinking more of it: +1. |
| 4 |
> > This would throw away the sed-hacks in gnulib.ebuild itself, and allow |
| 5 |
> > use of 'gnulib-tool --create-testdir' without any additional hacks. |
| 6 |
> > |
| 7 |
> > Simply create the gnulib 'testdir' in "${WORKDIR}/gnulib" like done now |
| 8 |
> > in gnulib.ebuild, and let C{,XX}FLAGS and LDFLAGS point there. |
| 9 |
> > And if done by an ebuild function it could just do nothing on [[ CHOST |
| 10 |
> > == *-linux* ]] or even on 'use elibc_glibc'. |
| 11 |
> > |
| 12 |
> > And if we find out many packages using similar sets of gnulib modules, |
| 13 |
> > we could create some intelligent cache for libgnu.a... |
| 14 |
> |
| 15 |
> I initially had in mind sort of the same, but with the cache in the back |
| 16 |
> of my head. Given that you require getopt some and other, you just need |
| 17 |
> to get those .o files in a libgnu.a. I don't think a .a file with more |
| 18 |
> than you need is a problem (the linker extracts only what it needs, I |
| 19 |
> guess), which means one can simply create the archive of all .o files |
| 20 |
> available. If we'd just have a directory somewhere, where Portage dumps |
| 21 |
> the .o files to, creating the gnulib.a would be trivial, and the cache |
| 22 |
> would be there immediately. Given that it's probably a zipf |
| 23 |
> distribution, the cache would be highly beneficial right from the start, |
| 24 |
> so why not just do it that way? |
| 25 |
|
| 26 |
It's not that easy: gnulib .o files have dependencies on others. |
| 27 |
Additionally there are some headers, which must match the objects when |
| 28 |
used. And some of these headers hide system headers, or do #include_next |
| 29 |
on them, with some wrappers #defined. |
| 30 |
|
| 31 |
(defining term "libgnu" to "libgnu.a and the headers" here) |
| 32 |
|
| 33 |
We could recreate the cached "libgnu" from scratch each time a package |
| 34 |
requires another gnulib module not in the cache yet. |
| 35 |
But I'm afraid this breaks already-installed packages when remerged, as |
| 36 |
their configure might find another gnulib module available then, while |
| 37 |
they could still work without it. |
| 38 |
The difference to the non-cached libgnu out of gnulib.ebuild compared to |
| 39 |
a cached one is that such problems are reproducible using the non-cached |
| 40 |
one. |
| 41 |
|
| 42 |
This having said, I don't like one single growing _cached_ libgnu. |
| 43 |
Instead I'd cache one libgnu for each used set of gnulib-modules. |
| 44 |
This cache is pruned when reinstalling dev-libs/gnulib. |
| 45 |
|
| 46 |
This would result in something like |
| 47 |
/usr/lib/gnulib/getopt-strcasestr-xvasprintf/{include,lib}/ |
| 48 |
/usr/lib/gnulib/another-getopt-strcasestr-xvasprintf-yetanother/{include,lib}/ |
| 49 |
|
| 50 |
Or we go with the libgnu from gnulib.ebuild as done currently, and have |
| 51 |
this being the growing one, but easier to control. |
| 52 |
|
| 53 |
Btw, seems the solaris patch for portage-utils can be reduced from >20k |
| 54 |
to ~3k using gnulib. |
| 55 |
|
| 56 |
/haubi/ |
| 57 |
-- |
| 58 |
Michael Haubenwallner |
| 59 |
Gentoo on a different level |
Archives