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

[Óscar Fuentes]

Michael Wild <themiwi at gmail.com> writes:

>>> 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.
>
>
> Sorry, but that is just a *LOT* of BS. Have you actually tried it?!

Have you actually read the thread?

> Check out the following:

[snip]

> That's right, -I/usr/include doesn't even show up ONCE, although I added
> it three times using include_directories().

Okay, cmake removes duplicated directories that already are on the
list. So what?

First, I hope that cmake does not optimize this series:

A B C A

... to this:

A B C

or to this:

B C A

Removing adjacent duplicates is fine, but removing duplicates in general
makes difficult to debug the build and may affect semantics.

Second, the topic here is that we are forced to jump through hops
because cmake tries to be helpful. It looks for files into places but
then it is up to us to figure out if those places must be added to the
list of header and library paths. That's not convenient at all, quite
the contrary, it is messy and confusing, as we are experiencing.