cmake's FIND_PATH and FIND_LIBRARY don't give priority to port-provided libraries over system-provided ones

[vvrbanc@…]

What happens is that cmake's FIND_PATH and FIND_LIBRARY functions don't detect that a port of a certain library is installed but rather uses system-provided one.

Example:

I have 3 versions of libxml2 in different directories

• /usr/lib
• /Library/Frameworks/libxml2.framework/libxml2
• /opt/local/lib/

and when calling FIND_PATH like this:

FIND_PATH(LIBXML2_INCLUDE_DIR libxml/xpath.h
   PATHS
   /opt/local/include
   PATH_SUFFIXES libxml2
   )

it returns /Library/Frameworks/libxml2.framework/Headers/libxml as the found path.

Cmake should give priority to port-provided libraries and headers.

This bug prevents "strigi" (prereq for kde4) from compiling because it doesn't work with apple's libxml2 and libiconv.

[cssdev]

According to the ​CMake FIND_PATH documentation. CMake will by default include several additional search locations. You need to set NO_DEFAULT_PATH if you do not want CMake to search those additional locations. As noted on that page, you can fine-tune the excluded default paths. CMake is working correctly based on that page, and you need to fine-tune its search behavior according to your need to explicitly avoid the system paths.

[vvrbanc@…]

Ok, you could say that cmake is working as designed, then.

However it shouldn't be left up to the user to keep track of this. Installing macports should be more streamlined and user friendly. If a macport won't compile using some libraries/frameworks that the user may already have outside of macports installation, that port's makefile should set the search path to only include the macports version of that library.

One example of this behavior is the packet "strigi" which won't compile using the system-provided libiconv or libxml2.

I propose we close this issue and open new tickets in those offending ports.

[cssdev]

A MacPorts user can modify his/her environment according to the documentation. From the port maintainership perspective, I think that ports which don't explicity link against the correct MacPorts-provided libraries are indeed broken and need separate bugs.

[(none)]

Milestone Port Bugs deleted