On 29. Jan, 2011, at 3:06 , Óscar Fuentes wrote:
> Michael Wild <them...@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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
