[CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

[Eric Noulard]

Le mer. 6 mars 2019 à 21:33, Stewart, Robert <Robert.Stewart at sig.com> a
écrit :

> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on
> different platforms).  In so doing, our CMake invocation of CPack to create
> RPMs now fails and I'm hoping someone can help.  I have a spec file and I
> want to run rpmbuild -bb, but I can't figure out how to do it.
>
> We have been using a custom spec file all along, but I found information
> indicating that doing so is (now?) considered a hack and that everything
> should be possible merely by setting CPACK_* variables.  Unfortunately,
> that's not the case.


Which CPACK_xxx variables did you use?
CPACK_RPM_SPEC_MORE_DEFINE ?
CPACK_RPM_USER_FILELIST ?



> With the following %files entries, CPackRPM.cmake chokes:
>
> %defattr(-, %{user}, %{group}, 0755)
> %dir %{destination}
> %dir %{versioned}
> %dir %{foo}
> %{foo}/*.sh
> %attr(555, %{user}, %{group}) %{foo}/a
> %dir %{bar}
> %attr(544, %{user}, %{group}) %{bar}/b
> %attr(444, %{user}, %{group}) %{bar}/*common
> %{bar}/lib
>
> The result is that my attempt to port to the all-variable approach failed,
> so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as
> before.  Unfortunately, when I do so, CPackRPM.cmake doesn't set
> RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful.  The issue
> is in the following code:
>
>     # We should generate a USER spec file template:
>     #  - either because the user asked for it :
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
>     #  - or the user did not provide one : NOT
> CPACK_RPM_USER_BINARY_SPECFILE
>     if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>       set(RPMBUILD_FLAGS "-bb")
>
> I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I
> include CPack, but that isn't propagated to CPackRPM.cmake.  I tried adding
> a custom target that invoked "${CMAKE_CPACK_COMMAND} -D
> RPMBUILD_FLAGS=-bb", but that didn't work either.
>

You cannot add flags meant to be used at CPack time in your CMakeLists.txt
because CMakeLists.txt is read when *cmake* runs not when *cpack* runs.
See:
https://github.com/dev-cafe/cmake-cookbook/tree/master/figures/cmake-times
for the description of various times

However you can use
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for that purpose.
If you specify (in your CMakeLists.txt) the name of a file as
set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_BINARY}/mycpack_config.cmake)
then the 'mycpack_config.cmake' will be processed by CPack when it runs.
You can find an example usage here:
http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt#n621
in this case the CERTICPackOptions.cmake.in  (in the source tree) is first
configure to CERTICPackOptions.cmake (in the build tree)
then
SET(CPACK_PROJECT_CONFIG_FILE "${CERTI_BINARY_DIR}/CERTICPackOptions.cmake")

indicate that CPack should use it at "CPack-time".

The process describing how "CPACK_PROJECT_CONFIG_FILE" is used is described
at the beginning of : https://cmake.org/cmake/help/v3.12/module/CPack.html

If the regex processing of the %files content were more robust, I wouldn't
> trip over the RPMBUILD_FLAGS issue,


Then may be you can file a patch for making those more robust?


> but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and
> since it is currently, it should be possible for me to set RPMBUILD_FLAGS.
>
> Ideas?


1) Use   CPACK_RPM_USER_BINARY_SPECFILE and CPACK_PROJECT_CONFIG_FILE.
2) propose a patch for

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190322/7db9ef72/attachment.html>