http://fedoraproject.org/wiki/PackagingDrafts/cmake
In short, adding to %cmake: -DINCLUDE_INSTALL_DIR=%{_includedir} \\ -DLIB_INSTALL_DIR=%{_libdir} \\ -DSYSCONF_INSTALL_DIR=%{_sysconfdir} \\ -DSHARE_INSTALL_PREFIX=%{_datadir}
Found these additions useful while working on kde4 packaging (SYSCONF_INSTALL_DIR in particular, since kde4's default was/is prefix/etc).
-- Rex
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake
I'm not even sure this kind of thing needs to go through the packaging committee. For example, I doubt rpm maintainers would consult us if they wanted to change, say, the %configure macro. This seems to me to be something best worked out between the cmake maintainer(s) and packagers who need the %cmake macro.
But if you want an ack, +1 assuming that the cmake-using packagers have been consulted.
- J<
Jason L Tibbitts III wrote:
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake
I'm not even sure this kind of thing needs to go through the packaging committee.
...
But if you want an ack, +1 assuming that the cmake-using packagers have been consulted.
(most) kde folks + cmake maintainer have been Cc'd (no other feedback yet).
-- Rex
On Tue, Jun 26, 2007 at 03:25:57PM -0500, Jason L Tibbitts III wrote:
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake
I'm not even sure this kind of thing needs to go through the packaging committee. For example, I doubt rpm maintainers would consult us if they wanted to change, say, the %configure macro. This seems to me to be something best worked out between the cmake maintainer(s) and packagers who need the %cmake macro.
But if you want an ack, +1 assuming that the cmake-using packagers have been consulted.
+1 from me, too. Like Jason says it's probably an implementation detail and for example with redhat-rpm-config we've been only given recommendations and have not been feeling authoritatively (maybe it's a grey zone in the FPC's mandate), but if it's considered out business to decide +1 with an FPC hat on, as well. :)
Rex Dieter wrote:
http://fedoraproject.org/wiki/PackagingDrafts/cmake
In short, adding to %cmake: -DINCLUDE_INSTALL_DIR=%{_includedir} \\ -DLIB_INSTALL_DIR=%{_libdir} \\ -DSYSCONF_INSTALL_DIR=%{_sysconfdir} \\ -DSHARE_INSTALL_PREFIX=%{_datadir}
Found these additions useful while working on kde4 packaging (SYSCONF_INSTALL_DIR in particular, since kde4's default was/is prefix/etc).
-- Rex
Basically looks good to me. Here's what I propose:
# # Macros for cmake # %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %__cmake %{_bindir}/cmake
%cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %__cmake \\ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\ -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\ -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \\ -DLIB_INSTALL_DIR:PATH=%{_libdir} \\ -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\ -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\ %endif \ -DBUILD_SHARED_LIBS:BOOL=ON
I'll put in devel and recompile my cmake projects against it.
On Wednesday 27 June 2007, Orion Poplawski wrote:
[...]
%_cmake_lib_suffix64 -DLIB_SUFFIX=64
[...]
-DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\
[...]
%if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\ %endif \
[...]
Are the separate lib64 suffix tricks still needed after the introduction of -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} ?
Ville Skyttä wrote:
On Wednesday 27 June 2007, Orion Poplawski wrote:
[...]
%_cmake_lib_suffix64 -DLIB_SUFFIX=64
[...]
-DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\
[...]
%if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\ %endif \
[...]
Are the separate lib64 suffix tricks still needed after the introduction of -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} ?
Not sure 100% (I'd guess no), hence my comment at the bottom of the proposal:
Consideration: Now that LIB_INSTALL_DIR is used, the %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be omitted. I'm not advocating that, since I see no harm in setting both LIB_INSTALL_DIR and LIB_SUFFIX.
On Wednesday 27 June 2007, Rex Dieter wrote:
Consideration: Now that LIB_INSTALL_DIR is used, the %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be omitted. I'm not advocating that, since I see no harm in setting both LIB_INSTALL_DIR and LIB_SUFFIX.
With LIB_INSTALL_DIR=/usr/lib64 and LIB_SUFFIX=64 I could imagine some things ending up in /usr/lib6464. If there's evidence that suggests or "guarantees" this won't happen, I have no problem with it either.
Ville Skyttä wrote:
On Wednesday 27 June 2007, Rex Dieter wrote:
Consideration: Now that LIB_INSTALL_DIR is used, the %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be omitted. I'm not advocating that, since I see no harm in setting both LIB_INSTALL_DIR and LIB_SUFFIX.
With LIB_INSTALL_DIR=/usr/lib64 and LIB_SUFFIX=64 I could imagine some things ending up in /usr/lib6464.
Not in my kde4 packaging work so far... :)
If there's evidence that suggests or "guarantees" this won't happen, I have no problem with it either.
We can always change/fix it later, if problematic cases present themselves.
-- Rex
packaging@lists.fedoraproject.org