| 1 |
On Sat, 1 Sep 2012 01:05:39 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> On Fri, 31 Aug 2012 17:49:34 -0400 |
| 5 |
> Alexis Ballier <aballier@g.o> wrote: |
| 6 |
> |
| 7 |
> > On Fri, 31 Aug 2012 22:53:35 +0200 |
| 8 |
> > Michał Górny <mgorny@g.o> wrote: |
| 9 |
> > |
| 10 |
> > [...] |
| 11 |
> > > I'm not sure if you're aware of it but Gentoo doesn't aim at |
| 12 |
> > > supporting solely Linux and no other system. |
| 13 |
> > |
| 14 |
> > elf != linux |
| 15 |
> |
| 16 |
> Gentoo != elf only. |
| 17 |
|
| 18 |
Prefix? Come on, some usecases do not make pkgconfig so vital for every |
| 19 |
gentoo install that it should be in @system. |
| 20 |
|
| 21 |
> > > Also, please tell me how to handle multiple slots sanely without |
| 22 |
> > > pkg-config in a package like Boost, for example. |
| 23 |
> > |
| 24 |
> > You should know since you are proposing a boost-utils.eclass :) |
| 25 |
> |
| 26 |
> Eh, the world would be so much better if boost provided pkg-config |
| 27 |
> files. |
| 28 |
> |
| 29 |
> For example, boost.m4 (provided by boost-m4) uses some wall-dumb |
| 30 |
> stubborn heuristics which always grabs newest boost and doesn't |
| 31 |
> provide any sane way to provide it with an older one... |
| 32 |
|
| 33 |
Yes, pkgconfig can be useful, sometimes... |
| 34 |
|
| 35 |
> > Anyway, my point was just to go from 'not providing a .pc is broken' |
| 36 |
> > to '.pc are useful and needed in some cases but not all' |
| 37 |
> |
| 38 |
> But these some cases where there are needed result in the necessity |
| 39 |
> of installing them, and making the build systems aware of them. I |
| 40 |
> don't see much point in adding a 'backwards compatibility' to it as |
| 41 |
> well. |
| 42 |
|
| 43 |
If the build system needs pkgconfig then the ebuild should depend on |
| 44 |
it, whats wrong with that ? I dont need pkgconfig to run the package |
| 45 |
after its built. For the same reason people have been working to |
| 46 |
_remove_ flex, m4, bison, autoconf, automake from @system, pkgconfig |
| 47 |
does not belong there either... |
| 48 |
|
| 49 |
> Ah, while we're at it. If a library has macros referring |
| 50 |
> to the functions of another library (or just types) in its public API, |
| 51 |
> it needs a pkg-config file. ELF dependencies are not enough, |
| 52 |
> and the gold linker will refuse to work because of a missing explicit |
| 53 |
> dependency. |
| 54 |
|
| 55 |
Eh, straight to the point where pkgconfig is not the solution to |
| 56 |
everything: a binary not using said macros but trusting pkgconfig will |
| 57 |
get overlinked. Documentation stating that when using these |
| 58 |
macros/functions one should link to the other lib would make things |
| 59 |
even better. |
| 60 |
|
| 61 |
A. |
Archives