# Execute custom code (sed) when RPM SPEC is generated
**URL:** https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823
**Category:** Usage
**Tags:** os:linux, gen:makefiles
**Created:** [April 4, 2023, 2:29pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823 "2023-04-04T14:29:06Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@wdezell](https://discourse.cmake.org/u/wdezell)
#### Post date: [April 4, 2023, 2:29pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823/1 "2023-04-04T14:29:06Z")
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?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [April 4, 2023, 8:10pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823/2 "2023-04-04T20:10:52Z")
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?
---
### Author:  [@wdezell](https://discourse.cmake.org/u/wdezell)
#### Post date: [April 5, 2023, 12:14pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823/3 "2023-04-05T12:14:22Z")
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!
---
### Author:  [@wdezell](https://discourse.cmake.org/u/wdezell)
#### Post date: [April 5, 2023, 2:53pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823/4 "2023-04-05T14:53:20Z")
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.
---
### Author:  [@wdezell](https://discourse.cmake.org/u/wdezell)
#### Post date: [April 7, 2023, 4:01pm UTC](https://discourse.cmake.org/t/execute-custom-code-sed-when-rpm-spec-is-generated/7823/5 "2023-04-07T16:01:15Z")
The above correctly solved the issue, though the correct variable is **CPACK\_PACKAGING\_INSTALL\_PREFIX** , not CMAKE\_INSTALL\_PREFIX.
Thanks for clarifying a closed door and triggering the thought process which led to a correct solution instead of a kludge.