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

[Michael Wild]

On 29. Jan, 2011, at 3:06 , Óscar Fuentes wrote:

> Michael Wild <themiwi at gmail.com> writes:
> 
>>>> 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).
>>> 
>>> This is a moot point, because /usr/local/include and several other paths
>>> which are searched by default by cmake are not system directories in
>>> FreeBSD.
>> 
>> No it's not. If you have e.g. /usr/local/include/foo.h and you do
>> 
>> find_path(FOO_INCLUDE_DIR foo.h)
>> if(FOO_INCLUDE_DIR)
>>  include_directories("${FOO_INCLUDE_DIR}")
>> endif()
>> 
>> you don't have to care, because -I/usr/local/include will show up on the
>> command line. If foo.h happened to be in /usr/include, things would be
>> (kind of) fine again, because CMake filters that one out and thus
>> doesn't clutter your command line.
> 
> I said that it is a moot because what you describe is, precisely, what I
> was describing as problematic: the code above injects /usr/local/include
> on the preprocessor search list, after that another find_path (with a
> hard-coded path selected by the user) returns /home/joe/include and that
> is appended to the preprocessor search list. But if the user required a
> custom directory for the headers found with the second find_path
> possible is because he wants to override those installed on a
> system-wide directory such as /usr/local/include. If the user doesn't
> check the commands executed by `make', he will not notice that the build
> is using the headers stored in /usr/local/include.

Aaah, sorry, I didn't really understand the first time. So, basically this is the same problem as the one I described.

> 
>> After all, you do use CMake because it's smarter than your compiler.
>> Otherwise you could just use some dump shell script.
> 
> CMake and the compiler do very different tasks, their smartness can't be
> compared.

Well, in some other programming languages, the compiler itself takes care of all of this.

> 
> the find_* commands and the FindXXX modules in general works hard for
> finding things. I guess that if it where practical, they would be
> programmed for performing a complete filesystem scan. The fact that
> Unixes have a series of catch-all directories for headers and libraries
> and that cmake is used by people who don't know (nor care) about how it
> does its stuff and assume that it is a smart tool that does the Right
> Thing, is something that makes me think that that sort of nasty problems
> will happen from time to time. Unfortunately, what the Right Thing is
> can't be easily decided. I'm inclined to making everything explicit and
> not trying to be smart when that can cause subtle problems, but that's
> just me. I understand that others may prefer everyday convenience.


True. But usually the assumption is that a given package is either present in a system directory (i.e. /usr) or in at most one other prefix (per package).

> 
>>>> 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.
>>> 
>>> The semantics of #include is one of the most underspecified points of
>>> the C++ standard. It is up to the compiler vendor to decide what to do
>>> with #include. Each vendor uses its own algorithm (unless they decided
>>> on cloning the behavior of somebody else's compiler) and I've suffered
>>> subtle bugs due to that fact while porting applications. IIRC the
>>> standard says nothing about rewinding the search list for every lookup,
>>> but I'm ready to admit that in practice removing trailing duplicates
>>> makes no effect for all existing compilers and the vast majority of
>>> cmake users will appreciate that feature, although I wouldn't bet my
>>> neck on it.
>> 
>> That's true. But I bet that no vendor would be that insane to search the
>> include-directories in reverse order, or make it probabilistic, making
>> it more likely that a header gets picked up from a certain directory if
>> it is mentioned more often ;-)
> 
> :-)
> 
> Well, I must confess that when I wrote that removing trailing duplicates
> on the search path can affect semantics, I was thinking that it was
> actually true for some implementation, but at the same time I was unable
> to recall which one. No longer:
> 
> http://www.delorie.com/gnu/docs/gcc/cpp_11.html
> 
> #include_next is like #include but it doesn't rewind the search list. I
> would be quite surprised if there is no C/C++ software project that
> depends on having a duplicates (even adjacent duplicates!) on the search
> path.

But #include_next is GCC specific, used by the standard library authors to fix broken system headers. If somebody uses that include directive outside this scope, well, they are asking for trouble...

> 
>>>> But you could have found that out by yourself in about 20 seconds...
>>> 
>>> Please spare the inflammatory language for some other thread. Thanks.
>> 
>> Sorry for being snarky. I can only blame a foul mood due to a nasty cold
>> I caught...
> 
> No problem. It happens to me too (catching the flu and being snarky, not
> necessarily at the same time.)

;-)

> 
>>> Have I missed something?
>> 
>> I reiterate Andreas' answer from yesterday. But there IS one point where

ARGH... that should have read "I won't reiterate..."

>> the removal of system directories could wreak potential havoc, but even
>> then, there's nothing CMake could do about it. Assume this situation:

> [snip]
> 
> Agreed. This whole business is a can of worms. But I understand that
> CMake can't do much about it, apart from applying some checks that could
> alert the user that something is fishy. I'm not sure if it is worth the
> effort.


So far I haven't seen many complaints on this list. I have run into the problem myself some months back, but figured out what was going on pretty fast.

Michael