On 10/01/2011 01:35 PM, Rolf Eike Beer wrote: > Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling: >> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote: >>>> On 09/29/2011 06:15 AM, Yuri Timenkov wrote: >>>>> When I was investigating similar problem, I found alternative >>>>> approach >>>>> at >>>>> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.tx >>>>> t. >>>>> >>>>> The thing is to change linker rules, to something like this: >>>>> set(CMAKE_C_CREATE_SHARED_LIBRARY >>>>> >>>>> # standard rule >>>>> "<CMAKE_C_COMPILER> <CMAKE_SHARED_LIBRARY_C_FLAGS> >>>>> >>>>> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> >>>>> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> >>>>> <CMAKE_SHARED_LIBRARY_SONAME_C_FLAG><TARGET_SONAME> -o <TARGET> >>>>> <OBJECTS> >>>>> <LINK_LIBRARIES>" >>>>> >>>>> # now create a .debug copy >>>>> "${CMAKE_OBJCOPY} --only-keep-debug <TARGET> >>>>> <TARGET>.debug" >>>>> # link original to point at .debug copy >>>>> # directory components are removed, so "../lib/" is >>>>> fine >>>>> "${CMAKE_OBJCOPY} --add-gnu-debuglink=<TARGET>.debug >>>>> <TARGET>" >>>>> # Strip all information from target binary. >>>>> "${CMAKE_STRIP} --strip-debug --discard-all >>>>> --preserve-dates >>>>> >>>>> <TARGET>" >>>>> >>>>> ) >>>>> >>>>> I don't exactly remember benefits from this approach but it kind of >>>>> works. >>>> >>>> The benefits are that one needs to define these rule variables once as >>>> they're inherited by the subdirectories. The downside is that the rule >>>> variables are used by Makefile generators only, whereas the target- >>>> associated custom commands are a more generic approach. >>>> >>>>> And I agree that functionality like installing debug symbols in >>>>> install() >>>>> rules out of box would be quite handy. >>>> >>>> INSTALL() is essentially about copying files and directories, so it >>>> doesn't depend on the toolchain; in particular, you can use INSTALL() >>>> for projects which are configured with PROJECT(... NONE), i.e. without >>>> any toolchain. By contrast, extracting debug symbols does highly >>>> depend >>>> on the toolchain, e.g. the objcopy(1) utility isn't mentioned in >>>> POSIX, >>>> and even with the GNU tools, you have multiple possibilities to >>>> connect >>>> the stripped binary with the unstripped one, note --add-gnu-debuglink >>>> vs. build IDs. Windows and MacOSX will further enrich this entire zoo >>>> of utilities and command line switches, not to mention toolchains for >>>> specific platforms. So, opening and parameterizing INSTALL() - w.r.t. >>>> its interface and its implementation - in order to provide reasonable >>>> support for the extraction of debug symbols during installation is a >>>> major undertaking, IMO, besides the conceptional issue of toolchain- >>>> dependence. >>> >>> The idea was not to generate those during install, but to be able to let >>> them being installed. For e.g. MSVC you don't have anything to do, the >>> linker will already generate the PDB file already. So all you would have >>> to do would be to copy the generated debug file to the proper place. >>> This >>> whish comes from the fact that for multi-configuration generators you >>> don't know which configuration is active so you don't know where to >>> search the PDB file. And INSTALL() and ADD_CUSTOM_TARGET()/_COMMAND() >>> don't understand generator expressions. >> >> INSTALL() doesn't, but ADD_CUSTOM_TARGET/COMMAND() are right the two >> commands which *do* understand generator expressions. As long as you >> know the location of the debug files relative to the location of the >> concerned target's binary, the $<TARGET_FILE_DIR:target> expressions >> should do the trick. So, the worst case you might suffer is that you >> must use a custom target/command to copy or move the debug files to >> a suitable location in order to apply INSTALL(FILES ...) on them in >> the end. IMO, that's bearable; does it not work for you? However, >> adding generator expressions to the INSTALL() command might be >> worth a thought. >> >>> So my idea would be to generate the debug file during or after the link >>> step and save the position to this file somewhere internally, so >>> INSTALL(... DEBUG_SYMBOLS) would know which to take. Or to do just >>> nothing if we do not support external debug symbols on this platform. >> >> What do you mean with "save the position to this file somewhere >> internally"? Saving by a user's action, i.e. declaring a file as a >> debug file? If you know the file's name and location, you can simply >> apply INSTALL(FILES ...) on it, perhaps with an intermediate step as >> suggested above. Saving by action of CMake, i.e. without specifying >> the debug file's name and/or location? For this to work, you would >> need to teach CMake to recognize a debug file by itself, and that's >> probably a comparably complicated undertaking as teaching CMake how >> to generate debug files. > > I don't see how this is really complicated. You call objcopy with some > options. The only things that change for each call are the name of the input > and the one of the output file. The input file is obviously already known, > the > output file is something like inputfilename.debug in the simple case. > > You need a toolchain-specific rules for CMake to > -know if the toolchain has support for this at all (or if it is implemented) > -know how to generate the debug symbols file > -know how to find the debug symbols file for any target > > So for MSVC this would be { yes, do nothing as the linker already handles > this > for us, replace the extension of the output filename with ".pdb" }. For > gcc/g++ this would then be { yes, objcopy ... outputfilename > outputfilename.debug, append ".debug" to output filename }. With this you can > do INSTALL(... DEBUG_SYMBOLS ...) without much work. You currently have to do > something similar when you want to install a shared library with it's static > link library for MSVC. So this can't be all that hard.
With the GNU tools, e.g., there are two approaches to generate debug files: With objcopy's --only-keep-debug/--add-gnu-debuglink switches and with build IDs. For the latter, you need to pass the --build-id switch along with a suitable ID string to the linker, so the debug files' generation is no pure add-on step anymore. How do you think that one should parameterize this in order to let the user choose the objcopy approach or the build-ID approach or both - which is explicitly permitted - and possibly for each individual target? In general, one must be prepared that generating debug files - is an operation of the linker only (Visual approach) - is a linker-independent operation (objcopy approach) - is a combination of both (GNU/ELF build-ID approach) and in the most general case, it could be further influenced by parameters the user might want to set for each target individually, i.e. assuming that input/output filenames are the only variable things appears to be a trifle too short to me. For these reasons, I think that teaching CMake how to generate debug files - or to recognize them - via a generator/toolchain-independent interface will prove to be complicated. Regards, Michael >> E.g., with a typical *nix toolchain, CMake >> has no chance to know in advance *if* a debug file is generated, >> *where* it is written to and *what* is its name. > > You are right, the thing we did was a bunch of INSTALL(... OPTIONAL) and just > hope it to work right. > > 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