1 |
On Thursday 06 of September 2012 10:18:34 Brian Harring wrote: |
2 |
> On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote: |
3 |
> > On Tuesday 28 of August 2012 02:15:40 hasufell wrote: |
4 |
> > > Is there a reason not to support static-libs in an ebuild if the |
5 |
> > > package supports it? |
6 |
> > > |
7 |
> > > It seems some developers don't care about this option. What's the |
8 |
> > > gentoo policy on this? Isn't this actually a bug? |
9 |
> > |
10 |
> > A little remark. |
11 |
> > For CMake controlled buildsystem (as you're coming here from latest dev- |
12 |
> > games/simgear), there's no automatic way of building both static and |
13 |
> > shared libs (simgear allows to choose just one). |
14 |
> > This is why I removed static libs support that you proposed for dev- |
15 |
> > games/simgear (similar to ruby eclass abi handling - manually calling |
16 |
> > phases twice to build package 1st as shared, 2nd time as static). |
17 |
> > This is what I called "not worth the effort" in private discussion with |
18 |
> > you, not quite "I don't care for static libs" :) |
19 |
> |
20 |
> Guessing in the worst case, you can do a double compile to get around |
21 |
> this, no? And yes, that's freaking horrible, just verifying cmake |
22 |
> isn't doing something special that blocks it. |
23 |
|
24 |
Not sure why they would need to block it, one build dir for static, second one |
25 |
for shared. All safely separated (still stinks as a hack). |
26 |
|
27 |
> Is upstream doing anything about this, or is it not on their |
28 |
> radar/list-of-things-they-care-about ? |
29 |
|
30 |
Off the radar. |
31 |
|
32 |
CMake provides equivalent of '--enable-static --disable-shared' and '-- |
33 |
disable-static --enable-shared' by the means of BUIlLD_SHARED_LIBS and not |
34 |
specifying linkage when defining library: |
35 |
|
36 |
add_library(foo src1 src2) |
37 |
|
38 |
It doesn't automatically provide both at the same time however. CMake is |
39 |
cross-platform (meaning it support different generators: GNU Make, NMake, |
40 |
Visual Studio Project, XCode etc) so their main audience aren't "distros", |
41 |
also on Windows for instance when shared .dll is created, also import .lib is |
42 |
created. If static .lib was to be created as well, they would need to have |
43 |
separate build subdir for it (and a bit more complex library resolution |
44 |
algorithm). |
45 |
|
46 |
Still, if developer bothers enough to provide them both, he can easily |
47 |
implement it in buildsystem with explicitly given linkage (and separate target |
48 |
names): |
49 |
|
50 |
set(foo_SRC src1 src2) |
51 |
add_library(foo SHARED ${foo_SRC}) |
52 |
if (ENABLE_STATIC) |
53 |
add_library(foo_static STATIC ${foo_SRC}) |
54 |
endif () |
55 |
|
56 |
That being said I can understand why it's off the radar - technically |
57 |
everything is already available, likely not worth the effort and in many cases |
58 |
building both static/shared is actually not needed. |
59 |
|
60 |
-- |
61 |
regards |
62 |
MM |