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

[Michael Wild]

On 01/27/2011 04:49 PM, Óscar Fuentes wrote:
> 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.

The point I (and Andreas) wanted to make is that you can just add it. If
it's a system directory, CMake is going to filter it out (I didn't say
duplicates, I said "doesn't even show up ONCE", which means *zero* times).

And yes, CMake simplifies A B C A to A B C, which is perfectly fine
because the trailing A doesn't have any effect whatsoever. But you could
have found that out by yourself in about 20 seconds...

IMHO you're the one trying to jump through hoops that aren't even there...

Michael