[CMake] Wrong number of "../" elements in target path? 2.4.6 vs. 2.4.7 bug?

[Christian Convey]

OK, I've figured it out.  Consider the following code.  I use it to
decide, at cmake time, what subdirectories will be built in the
project (trust me - I have a reason to do it this way.)

Anyway, if a subdirectory (or descendant of a subdirectory) has a file
named "ExtraCMakeIncludeDirs.txt", then the directory containing that
file will later be added to the build using the ADD_SUBDIRECTORY()
command:

FILE(GLOB_RECURSE CUSTOM_ADDED_INCLUDES ./ExtraCMakeIncludeDirs.txt)
FOREACH(F ${CUSTOM_ADDED_INCLUDES})
  INCLUDE(${F})
  GET_FILENAME_COMPONENT(DIR ${F} PATH)
  MESSAGE("Adding supplemental source directory: " ${DIR})
  SET(IVP_DIRS_TO_BUILD ${IVP_DIRS_TO_BUILD} ${DIR})
ENDFOREACH(F)

The problem comes from the "./" on the first line of that code shown
above.  This results in an extra "./" appearing in the middle of the
pathnames emitted by the FILE(GLOB_RECUSE ...) command.

Somehow, CMake 2.4.6 gets thrown off track by that semantically
meaningless part of the  pathname.  My guess is that when the Unix
makefile generator is calculating the relative pathname to supply the
linker, its calculations get thrown off by the presence of "/./"
inside the path.

Anyway, for 2.4.6, I fixed this in my CMakeLists.txt file by simply
replacing "./ExtraCMakeIncludeDirs.txt" with
"ExtraCMakeIncludeDirs.txt".  And as I mentioned earlier, for some
reason this seems to just be a non-issue in 2.4.7.

Thanks everyone for the help.

- Christian