[CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

Andreas Pakulat <apaku at gmx.de> writes:

> On 27.01.11 16:13:09, arrowdodger wrote:
>> Hello. On FreeBSD everything, that distributes with system goes to /usr (i
>> mean includes go to /usr/includes and libs to /usr/lib) and all 3d party
>> stuff goes to /usr/local.
>> And the compiler is intentionally set to look only in /usr/include. The same
>> is for linker - it's looking for libs only in /usr/lib by default. So, if
>> user want to use some 3d-party library, he should add -I/usr/local/include
>> and -L/usr/local/lib to build command.
>> 
>> Now, i'm using find_library() and find_path() to locate 3d-party library in
>> such way:
>> 
>> > find_path(FFI_INCLUDE_PATH ffi.h PATHS ${USER_DEFINED_INCLUDE_DIR})
>> > find_library(FFI_LIBRARY_PATH ffi PATHS ${USER_DEFINED_LIB_DIR})
>> >
>> I'm expecting that search will not succeed until i supply CMake with
>> additional directories to search. But it's succeeds because
>> CMAKE_SYSTEM_PREFIX_PATH from Modules/Platform/UnixPaths.cmake is set to
>> "/usr;/usr/local;/". And this file is included by
>> Modules/Platform/FreeBSD.cmake.
>> 
>> Later i'm doing:
>> 
>> > if(${USER_DEFINED_INCLUDE_DIR})
>> >   include_directories(${FFI_INCLUDE_DIR})
>> > endif()
>> >
>> 
>> On FreeBSD it leads to "No such file or directory: ffi.h" error. So here is
>> the question: Is this a CMake bug?
>
> No, the bug is in your cmake code. You shouldn't use
> USER_DEFINED_INCLUDE_DIR to decide wether to add the path to the
> include-directories or not. Instead use the FFI_INCLUDE_PATH variable to
> decide that, it won't hurt if FFI_INCLUDE_PATH happens to be /usr/include.

FFI_INCLUDE_PATH will evaluate to TRUE whenever find_library succeeds,
which means that the path will always be added with
include-directories. This has two consequences:

 1. It pollutes the command line for the compiler. This is ugly and
 inconvenient while debugging the build.

 2. It affects the search order of include headers with subtle
 effects. An example: if you later execute another include_directories
 with a user-defined custom location for some set of headers that
 override those provided by the system, you have a problem because
 /usr/include already comes before the path you are adding.

> The reason cmake searches in /usr/local in addition to /usr is simply a
> convenience matter. Its a common prefix to have non-distribution software
> installed in and for the same reason things like /opt/local, /opt/csw and
> /usr/openwin are being searched for by default.

That's not a convenience here. We have to

if( we are on BSD )
  add paths /usr/local/include /opt/local/include etc
  same for libraries
endif()

which is ugly as hell, puts a lot of crap on the command line and may
create conflicts due to the altered search order.

IMO cmake should look by default on the directories where the compiler
automatically looks for. All other directories should be left for the
user to add, as he does while compiling something that picks a header or
library from a place not included on the default search path of the
compiler and linker.