Dear All,

I'm trying to do something a bit more complicated, so please bear with me...

In our project we use a special kind of source code generator. Called a 
"dictionary generator". (https://root.cern.ch/how/how-use-reflex) To simplify 
the life of our users a bit, we provide a helper function for generating 
"dictionary libraries", which has a signature like:

atlas_add_dictionary( MyDictLibrary
                      MyDictLibrary/MyDictLibraryDict.h
                      MyDictLibrary/selection.xml
                      INCLUDE_DIRS ...
                      LINK_LIBRARIES ... )

Now, in order to make sure that the dictionary generation command succeeds, we 
need to pull in the public include paths of all the libraries that this library 
is supposed to be linked against, recursively. To do this, I do the following 
behind the scenes:

foreach( l ${ARG_LINK_LIBRARIES} )
   # Skip physical libraries:
   if( EXISTS ${l} )
      continue()
   endif()
   # Skip generator expressions:
   if( ${l} MATCHES "[$]<" )
      continue()
   endif()
   # Get the include directories of this library:
   list( APPEND includes 
"$<TARGET_PROPERTY:${l}:INTERFACE_INCLUDE_DIRECTORIES>" )
endforeach()

As long as the users only specify either library targets, or absolute library 
path names here, this works well. But I just ran into some issues where this 
function is called with a system library name like "rt". So the project 
generation bails, complaining that "rt" is not a target.

Would it be possible to figure out in a generator expression if a given name is 
a target or not? Clearly I can't make this decision in an

if( TARGET ${l} )

statement, as the target may only get defined after this function call.

For now I'll be able to work around this issue, but I wonder if it would be 
possible to provide a full-proof implementation that would not be killed by the 
users specifying a low-level system library like this in the future.

Cheers,
           Attila
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to