| 1 |
On 31-07-2008 10:00:25 +0200, Michael Haubenwallner wrote: |
| 2 |
> Thinking more of it: +1. |
| 3 |
> This would throw away the sed-hacks in gnulib.ebuild itself, and allow |
| 4 |
> use of 'gnulib-tool --create-testdir' without any additional hacks. |
| 5 |
> |
| 6 |
> Simply create the gnulib 'testdir' in "${WORKDIR}/gnulib" like done now |
| 7 |
> in gnulib.ebuild, and let C{,XX}FLAGS and LDFLAGS point there. |
| 8 |
> And if done by an ebuild function it could just do nothing on [[ CHOST |
| 9 |
> == *-linux* ]] or even on 'use elibc_glibc'. |
| 10 |
> |
| 11 |
> And if we find out many packages using similar sets of gnulib modules, |
| 12 |
> we could create some intelligent cache for libgnu.a... |
| 13 |
|
| 14 |
I initially had in mind sort of the same, but with the cache in the back |
| 15 |
of my head. Given that you require getopt some and other, you just need |
| 16 |
to get those .o files in a libgnu.a. I don't think a .a file with more |
| 17 |
than you need is a problem (the linker extracts only what it needs, I |
| 18 |
guess), which means one can simply create the archive of all .o files |
| 19 |
available. If we'd just have a directory somewhere, where Portage dumps |
| 20 |
the .o files to, creating the gnulib.a would be trivial, and the cache |
| 21 |
would be there immediately. Given that it's probably a zipf |
| 22 |
distribution, the cache would be highly beneficial right from the start, |
| 23 |
so why not just do it that way? |
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
Fabian Groffen |
| 28 |
Gentoo on a different level |
Archives