-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2011 03:53 AM, Michael Hertling wrote: > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) > PROJECT(HEADERLIBRARY C) > SET(CMAKE_VERBOSE_MAKEFILE ON) > FILE(WRITE ${CMAKE_BINARY_DIR}/f.h "void f(void)\n") > ADD_LIBRARY(f STATIC f.h) > SET_TARGET_PROPERTIES(f PROPERTIES > LINKER_LANGUAGE C PUBLIC_HEADER ${CMAKE_BINARY_DIR}/f.h) > ADD_CUSTOM_COMMAND(TARGET f POST_BUILD > COMMAND ${CMAKE_COMMAND} -E remove $<TARGET_FILE:f>) > INSTALL(TARGETS f EXPORT f > PUBLIC_HEADER DESTINATION include > ARCHIVE DESTINATION include OPTIONAL) > INSTALL(EXPORT f DESTINATION share) > > Note the ARCHIVE DESTINATION *include* to prevent the INSTALL() command > from creating a directory for the non-existing library. The downside of > that approach is a little extra cost to build the empty library each > time make is run. > > Nevertheless, the export file created by INSTALL(EXPORT ...) will still > contain a reference to the non-existing libf.a, so I wonder what's the > point of using the INSTALL() command's EXPORT feature with a header- > only library, i.e. what's so bad with INSTALL(FILES ...) or - after > setting up the library's headers - with INSTALL(DIRECTORY ...)?
I tried that, and indeed there remains a reference to the libf.a. The idea is to have a single uniform mecanism to do export, all the more that things get more complex when you want to use the built library either at the build location or at the install location.... Since the EXPORT seems to be done for that, I expected it to work with INSTALL(FILES ...) or INSTALL(DIRECTORY ...) (exactly for headers) but it does not.... Honestly, headers seem sometimes a second class citizen in cmake: there are some properties related to headers but few header knowledgeable commands... On 04/05/2011 03:53 AM, Michael Wild wrote: > I don't see what the problem with install(FILES ...) is? If you have a > header-only library, you just don't need any of the complex EXPORT > stuff. That is only related to the dependencies between libraries, > executables and transitive linking. In the case of a header-only library > you dump the files, create a XXXConfig.cmake and XXXConfigVersion.cmake > file, and be done with. Well, I tend to disagree. Headers also have dependencies (to other headers or even to other libraries), so the concepts of transitive linking are useful as well for header-only libraries. Again, headers are a full part of software development, so (at least to me) it makes sense to treat them as well as libraries, executables,... That they happen to be readble and (usually) machine independent, does not mean that they do not convey dependencies, have version problems, ... I really think that having a target of type INCLUDES might bring consistency to cmake, and ease of use to users. If peope share this view, I might even try to add such a thing. For now, I guess I have to rely on INSTALL(FILES|DIRECTORY ...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2a2q0ACgkQEr8WrU8nPV12FgCeIDw5V0stl8pNcRRIVONNrvwz Y9AAoIjKekrhJZ3seSG2VthEqEQXaPWV =ew7D -----END PGP SIGNATURE----- _______________________________________________ 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