| 1 |
On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote: |
| 2 |
> On Tuesday 28 of August 2012 02:15:40 hasufell wrote: |
| 3 |
> > Is there a reason not to support static-libs in an ebuild if the package |
| 4 |
> > supports it? |
| 5 |
> > |
| 6 |
> > It seems some developers don't care about this option. What's the gentoo |
| 7 |
> > policy on this? Isn't this actually a bug? |
| 8 |
> |
| 9 |
> A little remark. |
| 10 |
> For CMake controlled buildsystem (as you're coming here from latest dev- |
| 11 |
> games/simgear), there's no automatic way of building both static and shared |
| 12 |
> libs (simgear allows to choose just one). |
| 13 |
> This is why I removed static libs support that you proposed for dev- |
| 14 |
> games/simgear (similar to ruby eclass abi handling - manually calling phases |
| 15 |
> twice to build package 1st as shared, 2nd time as static). |
| 16 |
> This is what I called "not worth the effort" in private discussion with you, |
| 17 |
> not quite "I don't care for static libs" :) |
| 18 |
|
| 19 |
Guessing in the worst case, you can do a double compile to get around |
| 20 |
this, no? And yes, that's freaking horrible, just verifying cmake |
| 21 |
isn't doing something special that blocks it. |
| 22 |
|
| 23 |
Is upstream doing anything about this, or is it not on their |
| 24 |
radar/list-of-things-they-care-about ? |
| 25 |
|
| 26 |
~harring |
Archives