Re: [gentoo-dev] supporting static-libs
On 09/22/2012 05:25 PM, hasufell wrote: > add_library(foostatic STATIC foo.cpp foo.h) > set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo) > add_library(foo SHARED foo.cpp foo.h) Looks a bit kludgy but should work well as a macro, willing to contact upstream and/or ask cmake devs to include it? Looks like you have a simple solution for this problem =) lu
Re: [gentoo-dev] supporting static-libs
On 09/22/2012 05:15 PM, Luca Barbato wrote: > On 09/03/2012 10:54 PM, 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). > > Complain to cmake devs, hopefully they might come up with a solution. > (the alternative is provide a clean autotools-based build system and ask > upstream to please keep both. Usually works nice to cover all bases and > make all people happy ^^; > > lu > It's a matter of 15minutes work to patch a cmake build system to allow installation of both. You can let cmake rename targets, so you have target library "foo" and "foostatic", but the latter will be renamed to "foo" as well. e.g.: add_library(foostatic STATIC foo.cpp foo.h) set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo) add_library(foo SHARED foo.cpp foo.h)
Re: [gentoo-dev] supporting static-libs
On 09/03/2012 10:54 PM, 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). Complain to cmake devs, hopefully they might come up with a solution. (the alternative is provide a clean autotools-based build system and ask upstream to please keep both. Usually works nice to cover all bases and make all people happy ^^; lu
Re: [gentoo-dev] supporting static-libs
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.
Re: [gentoo-dev] supporting static-libs
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. Is upstream doing anything about this, or is it not on their radar/list-of-things-they-care-about ? ~harring
Re: [gentoo-dev] supporting static-libs
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" :) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] supporting static-libs
On 28/08/2012 15:36, Mart Raudsepp wrote: > static-libs is for installing static libraries IN ADDITION to shared > libraries, not instead. > USE=static is for what you have in mind there. PE is not the same as ELF so on Windows you either build one or the other for a number of reasons. Now on a different note, this is not even what USE=static is for — but that's way behind what we were discussing before. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] supporting static-libs
On N, 1970-01-01 at 00:00 +, Gregory M. Turner wrote: > On 8/28/2012 1:09 AM, Michał Górny wrote: > > On Tue, 28 Aug 2012 02:15:40 +0200 > > hasufell wrote: > >> static-libs > > pointless > > I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay, > where one can have static or dynamic, but not both, as per. upstream > requirements (no idea why). So FTR, this is not always a matter of > personal taste. static-libs is for installing static libraries IN ADDITION to shared libraries, not instead. USE=static is for what you have in mind there. Best, Mart Raudsepp
Re: [gentoo-dev] supporting static-libs
On 8/28/2012 1:09 AM, Michał Górny wrote: On Tue, 28 Aug 2012 02:15:40 +0200 hasufell wrote: static-libs pointless I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay, where one can have static or dynamic, but not both, as per. upstream requirements (no idea why). So FTR, this is not always a matter of personal taste. -gmt
Re: [gentoo-dev] supporting static-libs
On Tue, 28 Aug 2012 02:15:40 +0200 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? Some people believe that IUSE=static-libs should be always used, I think, and they consider that to be a Gentoo policy. I believe that this is pointless to add it to every single library noone will ever use as static. I do add them when it's simple (i.e. with autotools-utils) and I know the package is supposed to work when linked statically. Otherwise, I'd just wait for someone to request static-libs support, much like we don't keyword ahead. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] supporting static-libs
On Tue, 2012-08-28 at 02:15 +0200, 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? For example, static linking is disabled in gtk+, pango, and gdk-pixbuf because they heavily rely on plugin loading. And anything that links to gtk+ should not be using static linking unless it wants to crash a lot.
Re: [gentoo-dev] supporting static-libs
On 27/08/2012 17:15, hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the package > supports it? Most libtool software "supports" static-libs, because libtool let you build them, _but_ it might not be test or might not even work. One example is software that relies on plug-ins, such as xine-lib. or stuff that links to gmodule. Having static libraries there is technically possible, but if you do you have a bag full of problems and nothing else. > It seems some developers don't care about this option. What's the gentoo > policy on this? Isn't this actually a bug? I honestly don't usually put static-libs "just because" — if a case can be made about static libs to be useful, I'm always open to add an USE flag, but "because I can" is not an option for me. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] supporting static-libs
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?