arpg/Calibu

Install metadata (exported targets, etc.) is broken

BrendanDrewDaqri opened this issue · 6 comments

Specific platforms where I have problems: OS X (El Capitan, XCode 7.3.1). The generated exports capture include locations and libraries for Calibu's dependencies, but not for Calibu itself. There are also several warnings that are generated. FWIW, I find the following fragments helpful when doing install / export targets (for each exported library / "module"):

install(TARGETS systemModuleName
        EXPORT systemTargets
        ARCHIVE DESTINATION lib
        LIBRARY DESTINATION lib
        COMPONENT module)

install(EXPORT systemTargets
        FILE systemTargets.cmake
        COMPONENT module
        NAMESPACE system::
        DESTINATION cmake)

@vikiboy: I believe you recently ran make install on Calibu (rather than relying on CMake exports); did you get any issues with downstream packages not finding libcalibu?

@BrendanDrewDaqri: are you running CMake with -DEXPORT_Calibu=ON or no?

@crheckman: I've tried setting that flag both ways. What's a little complicated here is that I'm pulling in Calibu as a dependency ("superbuild" in cmake parlance) via ExternalPackage_Add. After poking around a bit, it seems that the way the export data is being generate is confusing. I'm hacking on a clone that we have and if I find anything useful (I have some suspicions about how to get the include paths properly expressed to CMake to make the export work the way it "should")

BTW, if I should find a fix, I'm more than happy to share it but I'd like to make sure I've tested it on the right platforms before wasting your time.

It's definitely tough keeping all of our packages in shape for supporting brew, CMake and make install. It's no surprise it breaks other package management approaches. I appreciate the consideration you're giving to trying to find a solution.

If you're flip-flopping flags make sure you're doing them in clean build directories; I've found that CMake doesn't overwrite its own *Config.cmake files to reflect flopped flags.

This seems to work for me (note that I've gutted out all the matlab stuff
and applications, you'll need to do similar things in terms of install(...)
calls for those libraries / applications). There are two parts to the magic:

  1. using target_include_directories and target_link_libraries (this way,
    CMake can do all the tracking for you)
  2. when you install a target, add the EXPORT clause
  3. in the top-level CMakeLists, have the install(EXPORT ...) call

It'll take me a little while to back-port my changes (I did a pretty
thorough job butchering things in the clone I'm working from).

build calibu library

add_library( calibu ${SOURCES} )

foreach(CALIBU_INCLUDE ${CALIBU_INC})
target_include_directories(calibu PUBLIC
$<BUILD_INTERFACE:${CALIBU_INCLUDE}>)
endforeach()
target_include_directories(calibu PUBLIC $<INSTALL_INTERFACE:include>)
target_include_directories(calibu PUBLIC
$&lt;BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include>)
target_include_directories(calibu SYSTEM PUBLIC ${USER_INC})
target_link_libraries(calibu PUBLIC ${LINK_LIBS})

install everything

install(TARGETS calibu
EXPORT calibuExports
LIBRARY DESTINATION lib
PUBLIC_HEADER DESTINATION include/calibu
INCLUDES DESTINATION include/calibu)

install(DIRECTORY include/calibu
DESTINATION include/calibu)

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/include/calibu/config.h
DESTINATION include/calibu)

install(EXPORT calibuExports
DESTINATION cmake
NAMESPACE calibu)

On Thu, Jul 14, 2016 at 3:31 PM, Christoffer Heckman <
notifications@github.com> wrote:

It's definitely tough keeping all of our packages in shape for supporting
brew, CMake and make install. It's no surprise it breaks other package
management approaches. I appreciate the consideration you're giving to
trying to find a solution.

If you're flip-flopping flags make sure you're doing them in clean build
directories; I've found that CMake doesn't overwrite its own *Config.cmake
files to reflect flopped flags.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/APP1R2td6_QxV-el0Hyv5oBFB9Lqjnqzks5qVrjXgaJpZM4JM5m5
.

No, there weren't any issues with other packages not finding calibu. A simple make install was all that I did for calibu.

I just gave this a test, and it doesn't appear to support exporting from the build tree (https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets#Exporting_from_a_Build_Tree), which is a feature we have traditionally supported in our development environment.

I would have to know a bit more about the roadblocks you've hit with our current master branch to see what exactly is breaking. As I said, the current approach (which uses a dazzlingly arcane set of commands all wrapped up in install_package.cmake) at least supports traditional make install and exporting targets from the build directory, as well as those who tap our keg and use brew, but I would be very interested in supporting superbuilds if possible too.