Re: [CMake] Debuginfo builds and CPack RPM support
I would like for there to be support for debuginfo builds as well. This is essential in my use case, where I am debugging a huge program on a remote system with limited memory and a relatively slow network link. Having a separate symbol pacakge is the preferred way to debug remotely since symbols can be loaded on the client much faster than they can across a network, and without increasing the memory used on the system under test. Is there a feature open yet to track this request? A quick search of the backlog did not turn up anything. My alternative will be to continue to use my own packaging scripts. Thank you, --Edwin -- View this message in context: http://cmake.3232098.n2.nabble.com/Debuginfo-builds-and-CPack-RPM-support-tp7582538p7585833.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Debuginfo builds and CPack RPM support
On Mon, Dec 3, 2012 at 2:06 PM, Eric Noulard wrote:
>> 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, ...)
It's a macro that essentially expands to its own section; in my
testing, I've been able to put it at the end of the spec file with the
intended effect. It's visible in /usr/lib/rpm/macros on at least
Fedora, RHEL/CentOS, and Ubuntu (with RPM tools installed).
Relevant snippet starts with:
# Template for debug information sub-package.
%debug_package \
...
%package debug\
Summary: Debug information for package %{name}\
...
However, there is no option to change how this sub-package is named.
This causes a problem because of CPack's _rpmfilename.
>
>> 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?
I'm speaking specifically to _rpmfilename; I believe there's an open
issue on this. _rpmfilename can use placeholders with RPM (which RPM
subpackages utilize by appending the sub-package name to the package
name, however because CPackRPM uses a fixed string vs. variable
substitution, this can't be used. The default in RPM is
%%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm but CPack sets
this to a fixed literal.). For this approach to work, we'd at least
need to use an _rpmfilename with %%{NAME} in it, as %debug_package
will add a subpackage called 'debug' (resulting in a package name that
is %%{NAME}-%%{SUBPACKAGENAME} (e.g. foo-debug.rpm)
Ref: http://www.rpm.org/max-rpm/s1-rpm-subpack-spec-file-changes.html
It's going to be exceedingly difficult to do this without leveraging
RPM's %{NAME} var, at least during RPM building (we could rename
after). See below.
>
> Could you give me an example or a pointer explaining how this could be
> templated?
>
Here's how I can generate both packages, but of course CPack doesn't
know how to find them/rename them.
1) Changed spec file to %define _rpmfilename foo-0.42.0-Linux-%%{NAME}.rpm
(this had been foo-0.42.0-Linux.rpm as populated by CPackRPM.cmake)
2) Added %debug_package prior to %description, but it can go anywhere
3) Built with this spec file. This generated two RPM files:
foo-0.42.0-Linux-foo.rpm
foo-0.42.0-Linux-foo-debug.rpm
At this point, we could rename files to remove the extraneous %%{NAME}
from the name and then move anything foo-0.42.0-Linux*.rpm to the
right place.
> 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?
I verified that the RPM macros exist on CentOS, Fedora, Ubuntu (with
RPM tools), and Mandriva.
Joe
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Debuginfo builds and CPack RPM support
2012/12/3 Joe Nardone : > 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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Debuginfo builds and CPack RPM support
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.) 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.) 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. 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. Is anyone doing this now? Is there a way to have a single .spec file generate multiple RPMs that plays nice with CPack? Or is there an alternate way to generate debuginfo packages for RPM platforms within the confines of CMake/CPack? joe -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
