Opened 10 years ago

Closed 4 years ago

#41817 closed defect (fixed)

CMake @2.8.12_2: remove /sw paths from installed cmake modules

Reported by: cooljeanius (Eric Gallager) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: mojca (Mojca Miklavec)
Port: CMake

Description

Currently a bunch of cmake modules look in Fink's prefix for stuff:

Local-Admins-MacBook-Pro:~ root# port -q contents cmake | xargs file | grep text | cut -d\: -f1 | xargs grep -H /sw
/opt/local/share/cmake-2.8/Modules/FindBoost.cmake:      /sw/local/include
/opt/local/share/cmake-2.8/Modules/FindBoost.cmake:      /sw/local/lib
/opt/local/share/cmake-2.8/Modules/FindGDAL.cmake:      /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindGDAL.cmake:            /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindGDAL.cmake:    /sw
/opt/local/share/cmake-2.8/Modules/FindGTK2.cmake:#   * Get module working under MacOSX fink by adding /sw/include, /sw/lib
/opt/local/share/cmake-2.8/Modules/FindGTK2.cmake:            /sw/include
/opt/local/share/cmake-2.8/Modules/FindGTK2.cmake:            /sw/lib
/opt/local/share/cmake-2.8/Modules/FindGTK2.cmake:            /sw/lib
/opt/local/share/cmake-2.8/Modules/FindLua50.cmake:  /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindLua50.cmake:  /sw
/opt/local/share/cmake-2.8/Modules/FindLua50.cmake:    /sw
/opt/local/share/cmake-2.8/Modules/FindLua51.cmake:  /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindLua51.cmake:  /sw
/opt/local/share/cmake-2.8/Modules/FindOpenAL.cmake:  /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindOpenAL.cmake:  /sw
/opt/local/share/cmake-2.8/Modules/FindOpenThreads.cmake:        /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindOpenThreads.cmake:        /sw
/opt/local/share/cmake-2.8/Modules/FindOpenThreads.cmake:        /sw
/opt/local/share/cmake-2.8/Modules/FindPhysFS.cmake:  /sw # Fink
/opt/local/share/cmake-2.8/Modules/FindPhysFS.cmake:  /sw
/opt/local/share/cmake-2.8/Modules/FindProducer.cmake:    /sw/include # Fink
/opt/local/share/cmake-2.8/Modules/FindProducer.cmake:  /sw
/opt/local/share/cmake-2.8/Modules/FindSDL.cmake:      /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:           /sw
/opt/local/share/cmake-2.8/Modules/FindSDL_sound.cmake:             /sw
/opt/local/share/cmake-2.8/Modules/Findosg_functions.cmake:            /sw # Fink
/opt/local/share/cmake-2.8/Modules/Findosg_functions.cmake:            /sw # Fink
/opt/local/share/cmake-2.8/Modules/Findosg_functions.cmake:            /sw # Fink
/opt/local/share/cmake-2.8/Modules/Platform/Darwin-icc.cmake:set(CMAKE_SYSTEM_INCLUDE_PATH ${CMAKE_SYSTEM_INCLUDE_PATH} /sw/include)
/opt/local/share/cmake-2.8/Modules/Platform/Darwin-icc.cmake:set(CMAKE_SYSTEM_LIBRARY_PATH ${CMAKE_SYSTEM_LIBRARY_PATH} /sw/lib)
/opt/local/share/cmake-2.8/Modules/Platform/Darwin.cmake:  /sw        # Fink

I know the boost one in particular has caused build failures for me in the past. I don't know if it'd be too much work to patch them all, or reinplace all the instances of /sw, but it would probably be worth it to make sure MacPorts CMake builds do not find stuff installed with Fink.

Change History (8)

comment:1 Changed 10 years ago by larryv (Lawrence Velázquez)

Cc: css@… removed
Owner: changed from macports-tickets@… to css@…

comment:2 Changed 10 years ago by cssdev

I thought there's a FAQ somewhere, but generally I think the practice is that one should not install Fink and MacPorts on the same system. That's just going to be a recipe for trouble.

comment:3 in reply to:  2 Changed 10 years ago by cooljeanius (Eric Gallager)

Replying to css@…:

I thought there's a FAQ somewhere, but generally I think the practice is that one should not install Fink and MacPorts on the same system. That's just going to be a recipe for trouble.

Well, yeah, but on the off-chance that a user does, MacPorts should make sure that it properly ignores it. It's the same reason that MacPorts sanitizes all its environment variables and stuff, to specifically ignore software installed outside of its prefix.

comment:4 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:5 Changed 10 years ago by cssdev

CMake is designed to search all those places by default. My preferences:

  1. Don't install Fink or anything in /sw
  2. Explicitly set include paths in Portfiles to exclude picking up external libraries. If you know MacPorts provides the library, then it should be defined on the cmake command line.
  3. Ask upstream for the recommended way to handle this.

Only as a last resort would I want to manage patches for every single module file. The best solution still seems to be not to mix package managers.

comment:6 Changed 10 years ago by mojca (Mojca Miklavec)

Please keep in mind that you also patched Modules/FindFreetype.cmake by removing /usr/X11R6. The arguments that you don't want to patch every single module file or that one should explicitly define where to take the module from is equally true for FreeType.

While I agree that users should try to avoid installing Fink, I would also try to prevent these kind of problems from happening as long as there are reasonable ways to achieve this.

See also an ugly patch in a port that I maintain browser:trunk/dports/science/geant4/files/patch-cmake-Modules-Geant4InterfaceOptions.cmake.4100.diff. Despite everything I often still need to set:

configure.args-append \
                    -DX11_INCLUDE_DIR=${prefix}/include \
                    -DX11_X11_INCLUDE_PATH=${prefix}/include \
                    -DX11_X11_LIB=${prefix}/lib/libX11.dylib \
                    -DX11_SM_LIB=${prefix}/lib/libSM.dylib \
                    -DX11_SM_INCLUDE_PATH=${prefix}/include \
                    -DX11_ICE_LIB=${prefix}/lib/libICE.dylib \
                    -DX11_ICE_INCLUDE_PATH=${prefix}/include \
                    -DX11_Xext_LIB=${prefix}/lib/libXext.dylib \
                    -DX11_Xpm_INCLUDE_PATH=${prefix}/include \
                    -DX11_Xpm_LIB=${prefix}/lib/libXpm.dylib \
                    -DX11_Xft_INCLUDE_PATH=${prefix}/include \
                    -DX11_Xft_LIB=${prefix}/lib/libXft.dylib

and I simply don't understand the point. The configure-based installation seems more reasonable in some cases.

In my opinion there should be a way to globally set the search paths in CMake (and an option to prevent searching in those paths). I would try to talk to CMake developers to find a way to deal with these problems, but if we can't find a solution that suits everyone I would tend to agree with Eric that /sw should go.

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:7 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from css@… to michaelld@…

comment:8 Changed 4 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed

this no longer occurs

Note: See TracTickets for help on using tickets.