[CMake] Fwd: Save stripped debugging information

Michael Hertling mhertling at online.de
Thu Oct 13 11:20:01 EDT 2011


On 10/13/2011 08:26 AM, Yuri Timenkov wrote:
> See my comments inline.
> 
> I could make an implementation proposal, but I don't have time till the end
> of November. So this discussion is quite pointless.
> 
> On Wed, Oct 12, 2011 at 3:02 PM, Michael Hertling <mhertling at online.de>wrote:
> 
>> On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
>>> Hi Michael,
>>>
>>> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling <mhertling at online.de
>>> wrote:
>>>
>>>> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
>>>>> that's the problem: you don't know neither file name nor it's location,
>>>>> especially in multi-configuration generators.
>>>>
>>>> You *do* know a debug file's name and location, either because you must
>>>> generate it explicitly (objcopy approach) or via the concerned target's
>>>> $<TARGET_FILE_DIR:...> generator expression in custom targets/commands
>>>> (Visual approach). Otherwise, a debug file with unknown name and/or
>>>> location would be rather useless.
>>>>
>>> I'm sorry that you misunderstood me, but I was concerned about install()
>>> commands.
>>>
>>> CMake already does a lot of things to make different platforms and
>>> generators work in same way. As it was noted before, install already
>> knows
>>> about such subtleties between generators and platforms like export
>>> libraries. So why not make it aware of separate debug information?
>>
>> Because, IMO, the platform/generator independent extraction and/or
>> recognition of debug info files is significantly more difficult to
>> specify than the handling of DLLs along with their import libraries
>> in VS, e.g. AFAICS, the latter works well since the import libraries
>> are generated next to their DLLs sharing the same base name,
> 
> Not exactly. Output path and filename can be overridden with /IMPLIB linker
> option. CMake just hard-codes this path.

That's what I had in mind; CMake can take care of import libraries with
regard to predictable names and locations since they are generated as a
by-product of the linking step, so they can flawlessly be installed by
the current means of the INSTALL() command. This does *not* apply to
debug info files on arbitrary platforms; their handling is just not
comparable with the import libraries' more regular one, IMO.

> and both
>> are covered by INSTALL()'s RUNTIME/ARCHIVE DESTINATION clauses which
>> also have a defined meaning on *nix. For VS alone, the installation
>> of debug info files would in fact be as easy as the installation of
>> an import library, but how would you specify and parameterize this
>> task on *nix?
> 
> It could be no-op if debug information is not separated, like installation
> of LIBRARY part of library is no-op on Unix. Or it could install debug info
> (separated with objcopy, as part of link step) as it is on VS. The latter
> case is applicable if policy dictates to copy/strip debug info.
> It's also possible to embed debug information into binary in VS (using /Z7
> compiler switch, at least for static library).

All this relies on CMake's knowledge of debug info files - where
they reside and what their names are. That's somewhat trivial with
VS but rather difficult on *nix, and it's the latter which I aimed
at with specifying/parameterizing. Of course, we might agree on a
convention that the debug info file for target xyz has to be named
xyz.debug and placed next to xyz - howsoever it is generated - but
this does not account for the diverse methods to extract the debug
information and, moreover, there wouldn't be a point to use another
INSTALL() subcommand than INSTALL(FILES ...) on xyz.debug, AFAICS.

[...]

>>>>> If it were possible to emulate vs behavior for gcc things would be much
>>>>> easier in some cases. [...]
>>>>
>>>> In which cases?
>>>>
>>> install debug into separate location for further usage, like generating
>>> "runtime" and "devel" packages. The third one is "debug".
>>
>> IMO, this is already possible with installation components:
>>
>> INSTALL(FILES <debug-files> DESTINATION ... COMPONENT debug)
>>
> You don't listen. The problem is not with components. [...]

Sorry if I don't have a clue - I use VS just occasionally - but what
exactly do you mean with "devel package", e.g.? Usually, "runtime"
and "devel" are typical installation components that are defined
with INSTALL(... COMPONENT ...) and subsequently installed with
${CMAKE_COMMAND} -DCOMPONENT=<component> cmake_install.cmake,
and a component "debug" does indeed perfectly go with this.

> [...] The problem is with
> determining original path name for multi-configuration generators. I's
> impossible to know what is <debug-files>.

It's impossible for *CMake* to know <debug-files> on *nix because their
are not generated as a by-product of the linking step with predictable
names. However, the *user* does know <debug-files> in any case - also
with multi-config generators - so it is well possible to install them
with INSTALL(FILES ...) by now, or is this proven wrong?

Admittedly, I'm still uncertain about our discussion's actual topic:

(1) Should CMake learn how to generate/recognize debug info files by
    itself in a platform/generator-independent manner so they can be
    simply installed by INSTALL(TARGETS ... DEBUG DESTINATION ...)?

(2) Should CMake just support the installation of debug info files
    with INSTALL(TARGETS ... DEBUG DESTINATION ...), but leave
    the generation and/or naming of those files to the user?

(3) In both cases, when CMake does know the debug info files'
    names and locations, what is the value added by

    INSTALL(TARGETS ... DEBUG DESTINATION ...)

    compared to

    INSTALL(FILES ... DESTINATION ...)?

BTW, please don't drop the ML.

Regards,

Michael


More information about the CMake mailing list