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

[Óscar Fuentes]

Michael Wild <themiwi at gmail.com> writes:

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

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.

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

> But you could have found that out by yourself in about 20 seconds...

Please spare the inflammatory language for some other thread. Thanks.

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

Okay, so if I have this:

check_include_file(foo.h HAVE_FOO_H)

and it succeeds, I have no guarantees that a program such as this:

#include "foo.h"

will compile, becasue foo.h may be found on a directory not included on
the compiler's default search list.

Okay, so I have to add something like

  figure_out_where_foo_h_really_is
  include_directories( where_foo_h_is )

Not nice, but let's go ahead.

We end having something like /usr/local/include (or /opt/local/include
or /opt/pkg/include etc) on the search list.

We now test for the presence of some third party library ("thelib"). We
have an user-settable variable for using just in case we want to use an
specific install, and we use it:

cmake -DTHELIB_IS_HERE=/home/oscar/thelib .

The search mechanism for thelib looks into that directory first and
succeeds, as it should. We add the corresponding directory:

include_directories( ${THELIB_INCLUDE_PATH} )

But there is another install of thelib on /usr/local, and that install
is the one that will be used by our build because we end having this
search list:

/usr/local/include /home/oscar/thelib/include

Have I missed something?