[CMake] Debuginfo builds and CPack RPM support

Eric Noulard eric.noulard at gmail.com
Mon Dec 3 14:06:40 EST 2012


2012/12/3 Joe Nardone <jnardone at gmail.com>:
> I'm struggling to figure out the right way to support debuginfo packages
> using CPack RPMs.  (Debuginfo packages contain the debug symbols from
> binaries that are otherwise stripped.)

CPackRPM wasn't designed with the handling of "*debuginfo" in mind.

> The canonical way on conformant platforms is to include %debug_package in
> the SPEC file, which triggers a number of actions, namely to
> find-debuginfo.sh (which creates the debug files and generates a sub-package
> in the RPM spec that includes this.)

Where should the %debug_package be placed in the spec file?
i.e. in which section (prep, build, install, ...)

> However, CPack's RPM generator does not play nice with this.  Since it has a
> fixed RPM name and not a template, what ends up happening is the sub-package
> overwrites the main installer (using the same name).  Attempts to change the
> rpm name to a template confuse the upstream CPack, which assumes a single
> installer with the same name as it provided to the module.

What do you mean by a "template"  do you mean that the
"Name:           package_name"
could be templated in some way?

Could you give me an example or a pointer explaining how this could be
templated?

The problem you discovered is the fact that CPack must know how many
package files (with their name) are spitted out from rpmbuild in order to move
them from CPack private location to the root of the build tree at the
end of the process.

We could make CPackRPM aware of debuginfo feature by adding a new
CPACK_RPM_DEBUGINFO which would trigger the feature.

Is the debuginfo generation distribution-specific or is it the same
for Fedora, Mandriva, OpenSuSE or any other RPM-based distro?

> You can't really use installer components here because the debug info
> generation assumes an install-type tree to work with, which only happens
> during packaging.  I don't see a way to identify all of the things that
> *would* be installed prior to actual install from inside CMake.

I don't get this part?


> Is anyone doing this now?  Is there a way to have a single .spec file
> generate multiple RPMs that plays nice with CPack?

Yes certainly but probably not without patching CPack.

> Or is there an alternate way to generate debuginfo packages for RPM platforms within the confines of CMake/CPack?

None that I am aware of but would you file a bug/features request
report explaining
the issue I may work on it.
I cannot offer deadline but from the description it doesn't seem
to be too hard to do at least for monolithic packages..


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org


More information about the CMake mailing list