> On 10/03/2011 09:18 AM, Yuri Timenkov wrote: >> Hi Michael, >> >> On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling >> <mhertl...@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, 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? With the GNU toolchain, CMake can't know in advance if > and how debug info files are generated, where they're written to etc.
I think you got something reverse here. To actually get the debug information in a separate file with binutils you need to run objcopy. You _specify_ to objcopy where to put the debug file. So CMake would need to specify this, i.e. can always know where these files end up. The build-id thing is optional, and as far as I understand this the primary use case is to find the debug symbols corresponding to an executable. The usual thing with gnu-debug-link is still done on those binaries, so the build-id thing is on top of that. This would only affect the install stage at all, i.e. if CMake would install these debug symbols in the global debug directory. So, to make things short: -call objcopy with target filename and the output filename -> both come from CMake, no magic -optionally, and only on installation, check if the file has a build-id (using readelf, objdump or whatever) and place a link from /usr/lib/debug/.build-id (or whereever) to the debug file So AFAICT there is no magic knowledge or searching for something involved at all. Or am I getting something seriously wrong here? Eike -- 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
