I have a very small library called pi-events, and I’m trying to install it locally to another project I have called sdl-sandbox, which lives in D:/projects/sdl-sandbox
My pi-events-config.cmake.in file looks like this:
Obviously this is going to cause some problems, b/c like I said, the sdl-sandbox project lives in D:/projects, not C:/Program Files (x86)
This is how I’ve defined pi-events-targets:
# create and install the target files
install(EXPORT pi-events-targets
FILE pi-events-targets.cmake
NAMESPACE pi::
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/pi/events)
I’m entirely sure if this is the only relevant information, but I wasn’t sure if I should dump the whole CMakeLists.txt file here, so let me know if more info is needed.
Is there anyway I can configure @PACKAGE_INIT@ to use the correct prefix dir?
It might also be that you have not set CMAKE_INSTALL_PREFIX, so it defaults to Program Files.
Actually, that is most definitely the reason, I wasn’t thinking straight at first
I haven’t set CMAKE_INSTALL_PREFIX, but when I install I use the command cmake --install . --prefix ../path/to/project. It installs all my library and target files exactly where I expect, but when I try to use find_package(pi-events REQUIRED) it can’t find it, seemingly because the package config helpers generated a file that uses the wrong prefix
I don’t wanna install to the user package base, because this is a hobby project that changes a lot, and I’d rather just install the library directly to local projects for now.
Though I suppose installing to the user package root would likely make my life easier.
That’s why I mentioned CMAKE_INSTALL_PREFIX - without it installation prefix will default to Program Files (in case of Windows). Not sure if --prefix plays the same role, I never used it before.
I’m pretty sure it does, like I said, all the library and target files get installed exactly where I expect them to, but the package config file doesn’t set up the local project to be able to find the newly installed library, because the generated file is looking in the wrong place (C:/Program Files (x86) instead of D:/projects). But I’ll try what you’re suggesting in case I’m wrong
This worked for getting the package prefix dir correct, but I’m unfortunately still unable to build my subproject because it can’t find the library package, which means there’s something else wrong
You mean get_filename_component(...) now doesn’t contain Program Files anymore?
still unable to build my subproject
How are you looking for it? And why you called it “subproject”? It seems I misunderstood what you are doing.
My understanding was that you build and install one project and then you find its installed package in another project via find_package() (and setting path to it in CMAKE_PREFIX_PATH).
Maybe subproject was a poor choice of words. You’re correct that I want to be able to find the installed package independently of the original library. I think I had an issue with my prefix path missing a directory, but I’m also running into other issues. I probably got it from here though. If I run into another road block, I’ll probably start a new topic if I can’t find any existing solutions online, since your suggestion fixed the problem I described in the topic name.
I’m now not entirely sure what the advantage is for setting up your library as a package if you’re not going to install to the user or global package root.
what the advantage is for setting up your library as a package
When a library is (correctly) installed as a (relocatable) package, then those who would like to use it in their project would only need to do the following:
find_package(pi-events CONFIG REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE pi-events) # pi::pi-events or pi::events
…and of course provide the path to that package in CMAKE_PREFIX_PATH on configuration.
That way users don’t need to know whether it is STATIC or SHARED, don’t need to manually set IMPORTED_LOCATION property (which requires them to look up the actual binary file name and its location), don’t need to set include directories for public headers and so on, because the package’s CMake config will do all that (and more) behind the scenes.
In addition, your library might have dependencies, and users will then need to manually add those to their projects as well, while with package’s CMake config that also can be managed “automatically” behind the scenes.
I guess this is what’s tripping me up. Like, I either need to set the specific path to the exported targets with set(CMAKE_PREFIX_PATH ...), or I need to set the specific path to the library files with set_property(... IMPORTED_LOCATION ...). With the former option, you also have to generate and install package target files. I suppose a package is more generalized though and may include additional information than just the path to the library.
I don’t think so, but it would be easy enough to confirm. Try the project with CMake 3.29.1 and 3.29.2. If the problem only occurs with 3.29.1, then MR 9390 would be the likely culprit. That change was reverted in 3.29.2.
