[cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!

[Alexander Neundorf]

On Tuesday 28 September 2010, Brad King wrote:
> On 09/28/2010 03:24 PM, Alexander Neundorf wrote:
> > Currently there are CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE.
> >
> > Should it be CMAKE_CURRENT_LIST_FILE_DIR or CMAKE_CURRENT_LIST_DIR ?
>
> Let's use the latter, CMAKE_CURRENT_LIST_DIR.
>
> -Brad


There should be a AddCMAKE_CURRENT_LIST_DIR branch now on the "stage".

Works, but still it doesn't feel good.
This means that whenever doing a 
include(FPHSA)
in one of cmakes find-modules it must actually be a
include(${CMAKE_CURRENT_LIST_DIR}/FPHSA.cmake)

Similar issues can come up with other files and in other projects.
In the end this would mean that in cmake basically all include()s would have 
to use the full path :-/

Another thing is, a few days ago I added an include guard to KDE's version of 
FPHSA.cmake, since it is included several times and it's quite long, so it 
should save some time:

--- trunk/KDE/kdelibs/cmake/modules/FindPackageHandleStandardArgs.cmake 
#1179966:1179967
@@ -67,6 +67,12 @@
 # (To distribute this file outside of CMake, substitute the full
 #  License text for the above reference.)
 
+# Include guard, it's not necessary to parse this fail again and again:
+IF(_FPHSA_ALREADY_INCLUDED)
+  RETURN()
+ENDIF(_FPHSA_ALREADY_INCLUDED)
+SET(_FPHSA_ALREADY_INCLUDED TRUE)
+
 INCLUDE(FindPackageMessage)
 INCLUDE(CMakeParseArguments)


(this is not yet in any release).

Thinking a bit about this, this has currently the following effect:

find_package(SomeKDEModule) -> loads KDE/FPHSA.cmake
find_package(SomeCMakeModule) -> loads CMake/FPHSA.cmake
find_package(SomeOtherModule) -> doesn't reload KDE/FPHSA.cmake due to 
                                 the include guard -> ok here, but might
                                 potentially also cause issues


So, avoid include guards completely ?
Or make them more intelligent ?
Like 

IF("${_FPHSA_ALREADY_INCLUDED}" STREQUAL "${CMAKE_CURRENT_LIST_FILE}")
  RETURN()
ENDIF()
SET(_FPHSA_ALREADY_INCLUDED "${CMAKE_CURRENT_LIST_FILE}" )

?
Still this requires that both versions would have to follow this include-guard 
style.

Another option would be that I check in KDE/FPHSA.cmake CMAKE_PARENT_LIST_FILE 
to see whether KDE/FPHSA.cmake is included from a module in cmake or in KDE, 
and if it's in CMake, forward that explicitely to CMake/FPHSA.cmake.
Unfortunately this doesn't seem work.
I just added the following to the top of my local FPHSA.cmake:

message(STATUS "parent: ${CMAKE_PARENT_LIST_FILE}")
message(STATUS "current: ${CMAKE_CURRENT_LIST_FILE}")

with the following in my CMakeLists.txt:

set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
find_package(DBusMenuQt)
find_package(ZLIB)


and hoped to see that I'm once include from 
${CMAKE_SOURCE_DIR}/FindDBusMenuQt.cmake, and in the 2nd case from 
${CMAKE_ROOT}/Modules/FindZLIB.cmake.

But instead CMAKE_PARENT_LIST_FILE was always the CMakeLists.txt:


-- parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
-- 
current: /home/alex/src/tests/cmake-fphsa/FindPackageHandleStandardArgs.cmake
-- parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
-- 
current: /home/alex/src/tests/cmake-fphsa/FindPackageHandleStandardArgs.cmake


Is this intended this way ?

Checking CMAKE_PARENT_LIST_FILE from inside the macro works OTOH, then I 
get /home/alex/src/tests/cmake-fphsa/FindDBusMenuQt.cmake 
and /opt/cmake-HEAD/share/cmake-2.9/Modules/FindZLIB.cmake respectively for 
CMAKE_CURRENT_LIST_FILE.

Alex