Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
-- Rex
################################# ## /etc/rpm/macros.cmake:
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
%cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %{_bindir}/cmake \\ %{?_cmake_install_prefix} \\ %{?_cmake_build_shared_libs} \\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\ %endif \
###############################3#
On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
1) This proposal doesn't handle %{_*dir}'s but _prefix I.e. it will break when any of them changes.
2) I don't like macros, once they have been introduced, you hardly can get rid of them.
Ralf
Ralf Corsepius wrote:
On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
- This proposal doesn't handle %{_*dir}'s but _prefix
I.e. it will break when any of them changes.
cmake doesn't use those other rpm macros anyway, so this proposal doesn't help/harm that. (:
-- Rex
On Tue, 2007-03-13 at 13:42 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
On Tue, 2007-03-13 at 13:05 -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
- This proposal doesn't handle %{_*dir}'s but _prefix
I.e. it will break when any of them changes.
cmake doesn't use those other rpm macros anyway, so this proposal doesn't help/harm that. (:
Yes, cmake is imake in new clothes: Hardcoded inflexibility ;)
Ralf
Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Updated PackagingDrafts/cmake to include proposed macro.
-- Rex
Rex Dieter wrote:
Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Updated PackagingDrafts/cmake to include proposed macro.
First off, your macro doesn't specify any source directory, which you must. That's actually good, because then you can do:
%cmake <path>
And it keeps the macro usage the same as the command usage.
I think you have to support out of tree builds as many projects actually don't support in tree builds (specifically, paraview). The question then becomes sub-dir or parallel-dir?
%build cd .. mkdir fedora cd fedora %cmake ../package-<ver>
or
%build mkdir fedora cd fedora %cmake ..
I'm not really sure there is a difference, but I've seen both in instructions from packages using cmake. I'll bring it up on the cmake list. The latter seems easier for building RPMS, and possibly required due to filesystem collision (unless you do something like mkdir package-<ver>-fedora).
Also, paraview gets built twice with different options in different dirs.
Orion Poplawski wrote:
Rex Dieter wrote:
Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Updated PackagingDrafts/cmake to include proposed macro.
First off, your macro doesn't specify any source directory, which you must. That's actually good, because then you can do:
%cmake <path>
And it keeps the macro usage the same as the command usage.
I think you have to support out of tree builds as many projects actually don't support in tree builds (specifically, paraview). The question then becomes sub-dir or parallel-dir?
Well, I wasn't aware of in-tree problems, so my first draft left out the details wrt out-of-tree builds.
Certainly the macros shouldn't touch which dir to use, leave that to users and specfiles.
-- Rex
Rex Dieter <rdieter <at> math.unl.edu> writes:
Well, I wasn't aware of in-tree problems, so my first draft left out the details wrt out-of-tree builds.
FYI, all the kde*4 modules don't support in-tree building. They recommend you to create a build subdirectory within the source directory, and use that as the build directory. I'm following that recommendation in my packaging (though any build directory other than the source directory should work).
Kevin Kofler
Hi,
On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros.
-- Rex
################################# ## /etc/rpm/macros.cmake:
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
%cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %{_bindir}/cmake \\ %{?_cmake_install_prefix} \\ %{?_cmake_build_shared_libs} \\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\ %endif \
###############################3#
Axel Thimm wrote:
Hi,
On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros.
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
-- Rex
On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote:
Axel Thimm wrote:
Hi,
On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros.
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
What would one override? They are already generic enough. If they really need changing then cmake will have changed so much that the %cmake macro would also not be valid anymore.
E.g. it would be like building %configure on blocks like
%_configure_bindir --bindir=%{_bindir}
Axel Thimm wrote:
On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote:
Axel Thimm wrote:
Hi,
On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros. %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
What would one override? They are already generic enough. If they really need changing then cmake will have changed so much that the %cmake macro would also not be valid anymore.
Then, do you have other method of overriding/omitting, say, -DBUILD_SHARED_LIBS:BOOL=ON from the build?
-- Rex
On Tue, Mar 13, 2007 at 03:55:42PM -0500, Rex Dieter wrote:
Axel Thimm wrote:
On Tue, Mar 13, 2007 at 03:18:30PM -0500, Rex Dieter wrote:
Axel Thimm wrote:
On Tue, Mar 13, 2007 at 01:05:48PM -0500, Rex Dieter wrote:
Appended is a first try at rpm macro'izing the the call to cmake per: http://fedoraproject.org/wiki/PackagingDrafts/cmake
I chose not to implement the out-of-tree style of build in the PackagingDraft to keep things simple(r).
Made each cmake option a separate macro to make in easier to override.
Comments?
do you need the _cmake_* macros for other things? If not, I would simply write the values into the %cmake macros. %_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
What would one override? They are already generic enough. If they really need changing then cmake will have changed so much that the %cmake macro would also not be valid anymore.
Then, do you have other method of overriding/omitting, say, -DBUILD_SHARED_LIBS:BOOL=ON from the build?
Would I ever want that? And in that case I would just not use %cmake. Same as if I don't want %configure to pass CFLAGS=%{optflags} etc.
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
What would one override? They are already generic enough.
Because KDE 4 needs to go to /opt/kde4 (or /usr/kde4 or some other prefix, but not /usr) or it will trip on KDE 3. For example, kdelibs-devel and kdelibs4-devel would clash on the .so symlinks if I packaged KDE 4 into /usr.
Kevin Kofler
On Thu, Mar 15, 2007 at 03:25:19AM +0000, Kevin Kofler wrote:
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
%_cmake_install_prefix -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} %_cmake_build_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_lib_suffix64 -DLIB_SUFFIX=64
Using _cmake_* macros allows for users to easily override/change individual items, if needed.
What would one override? They are already generic enough.
Because KDE 4 needs to go to /opt/kde4 (or /usr/kde4 or some other prefix, but not /usr) or it will trip on KDE 3. For example, kdelibs-devel and kdelibs4-devel would clash on the .so symlinks if I packaged KDE 4 into /usr.
You would set a different %{_prefix} then. I wasn't arguing about the use of %{_prefix}, that's more than fine.
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
You would set a different %{_prefix} then. I wasn't arguing about the use of %{_prefix}, that's more than fine.
Won't setting %{_prefix} make the package relocatable? I want to have cmake install into another prefix, but not make the RPM relocatable, because the prefix is hardcoded in at least kde4-config.
Kevin Kofler
On Sun, Mar 18, 2007 at 01:58:15AM +0000, Kevin Kofler wrote:
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
You would set a different %{_prefix} then. I wasn't arguing about the use of %{_prefix}, that's more than fine.
Won't setting %{_prefix} make the package relocatable?
At build time? No, it won't, and for truly being relocatable the package needs to support this at runtime, e.g. the build should not hardwire /usr and friends anywhere. Being relocatabale needs a lot of work at the source level.
I want to have cmake install into another prefix, but not make the RPM relocatable, because the prefix is hardcoded in at least kde4-config.
Same as for any other package:
rpmbuild --define '%_prefix /opt/my/stuff'
Or define _prefix somewhere more global as you will probably want to put more packages under your /opt hierarchy.
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
Won't setting %{_prefix} make the package relocatable?
At build time? No, it won't, and for truly being relocatable the package needs to support this at runtime, e.g. the build should not hardwire /usr and friends anywhere. Being relocatabale needs a lot of work at the source level.
No, my question was if it will make RPM _think_ the package is relocatable, even if it actually is not, which of course will screw up badly if the user really tries to relocate the package.
Kevin Kofler
On Tue, Mar 20, 2007 at 01:48:45PM +0000, Kevin Kofler wrote:
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
Won't setting %{_prefix} make the package relocatable?
At build time? No, it won't, and for truly being relocatable the package needs to support this at runtime, e.g. the build should not hardwire /usr and friends anywhere. Being relocatabale needs a lot of work at the source level.
No, my question was if it will make RPM _think_ the package is relocatable, even if it actually is not, which of course will screw up badly if the user really tries to relocate the package.
I understand what you mean - no, setting _prefix does not make a package relocatable. The long version follows:
Packages become relocatable by having a
Prefix: ...
tag. That's not how _prefix is set, _prefix is set like
%_prefix /usr
under /usr/lib/rpm somewhere, or even by %define _prefix ... in the specfile.
You will sometimes find
Prefix: / or Prefix: /usr or Prefix: %{_prefix}
That doesn't really set prefix, it tells rpm that you promise to install everything under that folder and nowhere else outside of it (rpmbuild will bail out otherwise) and that that part of the buildroot is relocatable.
Is it clearer or did I add to the confusion :)
Axel Thimm <Axel.Thimm <at> ATrpms.net> writes:
Packages become relocatable by having a
Prefix: ...
tag. That's not how _prefix is set, [...] Is it clearer or did I add to the confusion :)
That cleared it up.
Kevin Kofler
packaging@lists.fedoraproject.org
-
Axel Thimm -
Kevin Kofler -
Orion Poplawski -
Ralf Corsepius -
Rex Dieter -
Ville Skyttä