I have a need to modify the auto-generated SPEC file prior to the invocation of rpmbuild but install(CODE…) in the main CMakeLists.txt doesn’t trigger at the right time (the dynamic nature of our CI build doesn’t lend itself well to building user-provided spec file templates without going down a rabbit hole of keeping in sync with other distro package builds). A simple sed operation can fix what I need if I can just get to the spec before rpmbuild executes.
Is it possible to define a dependency-based trigger that can accomplish this at build time?
No I don’t think that is supported. From what I recall, cpack will generate the .spec file and then use that to produce the RPM. There is no hook to intervene between those two steps.
But you’ve come with a proposed solution to a problem you haven’t quite fully defined for us yet. Perhaps if you can provide details about the change you need to make to the spec file, there may be a way to avoid the need for that in the first place. Can you shed some light on what transformation you currently need to apply?
Thanks for the quick reply. I’ve been poring through the CPackRPM.cmake source and concluded much the same but was hoping there was some aspect I overlooked that might be exploitable.
The problem is that our very large project isn’t following recommended CMake best practices with respect to installation target path specification. We use a LOT of component variables that ultimately form absolute paths for the INSTALL() DESTINATION clauses and get flagged as ‘%config’ dirs and files in the generated SPEC. A current task to improve our installer by moving some post-installation script-managed tasks to now be under the authority of the package manager puts some content into these incorrectly-tagged directories at build time. They were formerly empty at build time and didn’t register as problematic (though they were). Now they break build-time UTs and will create very undesirable behavior if deployed. However, the offenders form a very simple pattern which would be easy to clear with sed if I could do it before the rpmbuild is invoked.
The correct fix is to use CMake/CPack as intended and change our pathing practices but we don’t have time to tackle a change of that scale and adequately test with code freeze being a week out. I’m also contemplating a user-supplied SPEC but the logic required to keep the dynamic content in sync with the other platform builds takes us away from one of the main beauties of CMake so is not appealing either. A kludge that produces a verifiably-correct result will do for this build.
Edit: I’ve been digging through my “Professional CMake 2nd Edition” for weeks now looking for angles. Fantastic book!
I think a better fix, and one that’s a migratory step towards better practices, would be to hard-code CMAKE_INSTALL_PREFIX as “/” for now and remove leading “/” from all path variables – they become “relative” and this problem goes away and we get to keep our installation assumptions until our code changes.
Incidentally, I remain curious about the CPackRPM generator design rationale as to why it chose to infer and assign this attribute based on absolute paths when it seems that CPACK_RPM_USER_FILELIST provides a good mechanism to manually assign the %config attribute as needed. I do agree, though, that relative path specification for targets is the preferable way to go.