[MacPorts] #51000: cmake-1.0: better support for relocation of libraries
#51000: cmake-1.0: better support for relocation of libraries -------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: -------------------------+-------------------------------- When changing `-DCMAKE_INSTALL_LIBDIR` I bumped into the following problem: * #50426 * http://bugzilla-geant4.kek.jp/show_bug.cgi?id=1848 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. -- Ticket URL: <https://trac.macports.org/ticket/51000> MacPorts <https://www.macports.org/> Ports system for OS X
#51000: cmake-1.0: better support for relocation of libraries --------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by michaelld@…): 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). -- Ticket URL: <https://trac.macports.org/ticket/51000#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#51000: cmake-1.0: better support for relocation of libraries --------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by mojca@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/51000#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts