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