Opened 11 years ago
Closed 5 years ago
#41720 closed enhancement (fixed)
cmake @2.8.12: hardcoded /opt/local
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | michaelld (Michael Dickens) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mkae (Marko Käning), cooljeanius (Eric Gallager) | |
Port: | cmake |
Description
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.
Change History (6)
comment:1 Changed 11 years ago by cssdev
comment:4 Changed 10 years ago by cooljeanius (Eric Gallager)
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
comment:5 Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | changed from css@… to michaelld@… |
---|
comment:6 Changed 5 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.