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

[Óscar Fuentes]

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.

> 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.

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.

>>> 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 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
> 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.