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 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/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 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 Tue, 28 Aug 2012 02:15:40 +0200 hasufell hasuf...@gentoo.org 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 8/28/2012 1:09 AM, Michał Górny wrote:
On Tue, 28 Aug 2012 02:15:40 +0200
hasufell hasuf...@gentoo.org 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 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 hasuf...@gentoo.org 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 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 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/
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.
