[MacPorts] #41720: cmake @2.8.12: hardcoded /opt/local
#41720: cmake @2.8.12: hardcoded /opt/local --------------------------+------------------- Reporter: ryandesign@… | Owner: css@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: cmake --------------------------+------------------- The following files in the cmake source tarball contain the string /opt/local, even if that is not the MacPorts prefix: {{{ cmake-2.8.12/Modules/FindGDAL.cmake cmake-2.8.12/Modules/FindGTK2.cmake cmake-2.8.12/Modules/FindLua50.cmake cmake-2.8.12/Modules/FindLua51.cmake cmake-2.8.12/Modules/FindOpenAL.cmake cmake-2.8.12/Modules/FindOpenThreads.cmake cmake-2.8.12/Modules/FindPhysFS.cmake cmake-2.8.12/Modules/FindProducer.cmake cmake-2.8.12/Modules/FindSDL.cmake cmake-2.8.12/Modules/FindSDL_sound.cmake cmake-2.8.12/Modules/Findosg_functions.cmake cmake-2.8.12/Modules/Platform/Darwin.cmake cmake-2.8.12/Source/CPack/cmCPackDebGenerator.h cmake-2.8.12/Source/CPack/cmCPackRPMGenerator.h cmake-2.8.12/Tests/Contracts/Trilinos-10-6/EnvScript.cmake cmake-2.8.12/Utilities/cmlibarchive/CMakeLists.txt }}} I noticed this, when a cmake-using port that succeeded building on a machine with MacPorts prefix /opt/local, failed to find gtk2 on a machine with a different prefix. We should probably reinplace /opt/local to the current prefix in these files, so that they can find the software they're supposed to be helping to find, even if the prefix is non-standard. While we're there, we should remove the parts of those files that would find software in /sw, /usr/local, and other locations we never want cmake to find software in. I already did a version of this with the patch to FindFreetype.cmake that I committed to the cmake port recently. -- Ticket URL: <https://trac.macports.org/ticket/41720> MacPorts <http://www.macports.org/> Ports system for OS X
#41720: cmake @2.8.12: hardcoded /opt/local ---------------------------+------------------- Reporter: ryandesign@… | Owner: css@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ---------------------------+------------------- Comment (by css@…): That sounds like a bug in the cmake-using port you're referencing. IMO it should explicitly pass the prefix into cmake when searching for the required libraries. Otherwise maintenance scope changes to include the task of modifying all of cmake's modules to automatically and transparently support loading files from the macports prefix while excluding all troublesome prefixes. That will lead to a massive collection of patches that have to be managed with each update. -- Ticket URL: <https://trac.macports.org/ticket/41720#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#41720: cmake @2.8.12: hardcoded /opt/local ---------------------------+------------------- Reporter: ryandesign@… | Owner: css@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ---------------------------+------------------- Comment (by egall@…):
While we're there, we should remove the parts of those files that would find software in /sw
Just for cross-referencing purposes, this is #41817 -- Ticket URL: <https://trac.macports.org/ticket/41720#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts