Opened 9 years ago
Last modified 9 years ago
#51000 new enhancement
cmake-1.0: better support for relocation of libraries
Reported by: | mojca (Mojca Miklavec) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | michaelld (Michael Dickens), ryandesign (Ryan Carsten Schmidt) | |
Port: |
Description
When changing -DCMAKE_INSTALL_LIBDIR
I bumped into the following problem:
Namely, cmake-1.0.tcl
sets -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib
plus some RPATH
-related variables that conflicted with the desired libdir setting. I fixed this in r147160, but it would be really nice if I didn't have to use
configure.args-delete -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib \ -DCMAKE_INSTALL_RPATH=${prefix}/lib -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
and then repeat the same setting as for -DCMAKE_INSTALL_LIBDIR
three times again. Then again I don't know what a better syntax should be. I'm fine wit adding all three variables again, I only don't particularly like the fact that I have to sniff which variables are set by default and then do acrobatics to remove them.
Change History (2)
comment:1 Changed 9 years ago by michaelld (Michael Dickens)
comment:2 Changed 9 years ago by mojca (Mojca Miklavec)
I would certainly propose to try to find some "wider context" to implement this. Rather than just solving one particular problem with one obscurely named variable, it would be nice to have some consistent syntax for different scenarios, I'm just not sure what these are.
I faintly remember problems of having to remove some CFLAGS
/ CPPFLAGS
/ LDFLAGS
like -L/path/to/libs
depending on whether autotools or CMake was used. Or #37732.
There is no rush, let's think it through.
And yes, it would be nice to set location of libraries just once rather than having to repeat the settings multiple times on top of having to delete individual flags.
Welcome to the world of CMake! With a bunch of options, it's often not easy to know exactly what to do for some specific issue, nor, when a method is selected, if it will work correctly. Most of the time CMake does the right thing and also works. But when it doesn't it's often a mystery what failed and why. Good for you tracking this one down!
Maybe these variables should be made optional but on & set like they are by default, sort of like the cmake.out_of_source option? That wouldn't change current functionality, and would be a cleaner solution than what you implemented. And, I'm quite sure some other ports would benefit from not setting these variables (either at all, or in the manner that works for most ports).