Hello,
Fedora KDE packaging guidelines have evolved over time, but official Fedora cmake guidelines [1] are still the same that were originally accepted in 2007.
I would like to propose a few changes to the example cmake spec file to bring it more in line with KDE spec files:
%build -%cmake . -make VERBOSE=1 %{?_smp_mflags} +mkdir -p %{_target_platform} +pushd %{_target_platform} +%{cmake} .. +popd + +make %{?_smp_mflags} -C %{_target_platform}
%install rm -rf $RPM_BUILD_ROOT -make install DESTDIR=$RPM_BUILD_ROOT +make install DESTDIR=$RPM_BUILD_ROOT -C %{_target_platform}
%check -ctest +make test -C %{_target_platform}
A few packages [2] [3] have recently had problems with the default -DBUILD_SHARED_LIBS:BOOL=ON which is part of %cmake macro. Those packages didn't pass neither SHARED nor STATIC arguments to add_library() call and relied on the cmake usual default to produce static libraries. Those static libraries weren't meant to be installed; they were just used as "convenience" libraries during the build which would be statically linked into the final executable.
However, if BUILD_SHARED_LIBS is defined, we get unversioned shared libraries instead of "convenience" libraries. Packagers often don't know what to do with such unversioned libraries.
Perhaps it'd be better to completely remove -DBUILD_SHARED_LIBS:BOOL=ON from the default %cmake macro? I would imagine that most (all?) libraries which are meant to be actually used as shared libraries contain explicit add_library(... SHARED) and set_target_properties(... PROPERTIES VERSION ... SOVERSION ...) calls, but maybe that's not how it is. Any thoughts whether removing BUILD_SHARED_LIBS=ON would break existing packages?
Anything else in the guidelines which needs discussion?
[1] https://fedoraproject.org/wiki/Packaging:Cmake [2] https://bugzilla.redhat.com/show_bug.cgi?id=539948 [3] http://lists.fedoraproject.org/pipermail/devel/2010-June/13771
Kalev Lember wrote:
Fedora KDE packaging guidelines have evolved over time, but official Fedora cmake guidelines [1] are still the same that were originally accepted in 2007.
I would like to propose a few changes to the example cmake spec file to bring it more in line with KDE spec files:
agreed.
...
Perhaps it'd be better to completely remove -DBUILD_SHARED_LIBS:BOOL=ON from the default %cmake macro?
also +1
-- Rex
2010/6/29 Kalev Lember kalev@smartlink.ee:
Hello,
%build -%cmake . -make VERBOSE=1 %{?_smp_mflags} +mkdir -p %{_target_platform} +pushd %{_target_platform} +%{cmake} .. +popd
I think we can't replace %{cmake} . with %{cmake} .. for all packages immediately. Sometimes, %{cmake} .. works improperly when using old cmake version(e.g. cmake 2.6.x in F12), cmake fails to copy sources to %{_target_platform} [1].
[1] http://cvs.fedoraproject.org/viewvc/rpms/pino/F-12/pino.spec?revision=1.11&a...
Regards, Chen Lei
On 06/28/2010 03:27 PM, Kalev Lember wrote:
A few packages [2] [3] have recently had problems with the default -DBUILD_SHARED_LIBS:BOOL=ON which is part of %cmake macro. Those packages didn't pass neither SHARED nor STATIC arguments to add_library() call and relied on the cmake usual default to produce static libraries. Those static libraries weren't meant to be installed; they were just used as "convenience" libraries during the build which would be statically linked into the final executable.
However, if BUILD_SHARED_LIBS is defined, we get unversioned shared libraries instead of "convenience" libraries. Packagers often don't know what to do with such unversioned libraries.
Perhaps it'd be better to completely remove -DBUILD_SHARED_LIBS:BOOL=ON from the default %cmake macro? I would imagine that most (all?) libraries which are meant to be actually used as shared libraries contain explicit add_library(... SHARED) and set_target_properties(... PROPERTIES VERSION ... SOVERSION ...) calls, but maybe that's not how it is. Any thoughts whether removing BUILD_SHARED_LIBS=ON would break existing packages?
Sorry for not replying earlier.
Looking at my existing cmake built packages, I'm a bit leery of this change. Most of them don't seem to specify SHARED in add_library. Has anyone tested this out on a large number of packages? Perhaps it makes sense to request a cmake koji build tag for this and rebuild all cmake built packages there.
On 07/14/2010 10:58 AM, Orion Poplawski wrote:
On 06/28/2010 03:27 PM, Kalev Lember wrote:
Perhaps it'd be better to completely remove -DBUILD_SHARED_LIBS:BOOL=ON from the default %cmake macro? I would imagine that most (all?) libraries which are meant to be actually used as shared libraries contain explicit add_library(... SHARED) and set_target_properties(... PROPERTIES VERSION ... SOVERSION ...) calls, but maybe that's not how it is. Any thoughts whether removing BUILD_SHARED_LIBS=ON would break existing packages?
Sorry for not replying earlier.
Looking at my existing cmake built packages, I'm a bit leery of this change. Most of them don't seem to specify SHARED in add_library. Has anyone tested this out on a large number of packages? Perhaps it makes sense to request a cmake koji build tag for this and rebuild all cmake built packages there.
Either way, I'm sure we'd be up to the task of clearly documenting the behavior change, and helping fix/cleanup any resulting messes.
Discounting how much actually breakage ensues, on principal how do you feel about this change?
-- Rex
On 07/14/2010 10:06 AM, Rex Dieter wrote:
On 07/14/2010 10:58 AM, Orion Poplawski wrote:
On 06/28/2010 03:27 PM, Kalev Lember wrote:
Perhaps it'd be better to completely remove -DBUILD_SHARED_LIBS:BOOL=ON from the default %cmake macro? I would imagine that most (all?) libraries which are meant to be actually used as shared libraries contain explicit add_library(... SHARED) and set_target_properties(... PROPERTIES VERSION ... SOVERSION ...) calls, but maybe that's not how it is. Any thoughts whether removing BUILD_SHARED_LIBS=ON would break existing packages?
Sorry for not replying earlier.
Looking at my existing cmake built packages, I'm a bit leery of this change. Most of them don't seem to specify SHARED in add_library. Has anyone tested this out on a large number of packages? Perhaps it makes sense to request a cmake koji build tag for this and rebuild all cmake built packages there.
Either way, I'm sure we'd be up to the task of clearly documenting the behavior change, and helping fix/cleanup any resulting messes.
Discounting how much actually breakage ensues, on principal how do you feel about this change?
I'm of two minds:
- It's good to have the %cmake macro has as little hidded vodoo in it as possible.
- Fedora strongly encourages shared libraries as shared libraries are good. If a package really wants a static library it should explicitly state it.
I'm fine for trying it, but we really should have a mass cmake rebuild afterwards to shake out the issues.
I'm moving this to fedora-devel to get more comment.
-
Chen Lei -
Kalev Lember -
Orion Poplawski -
Rex Dieter