[CMake] External project source

[Michael Hertling]

On 02/13/2012 09:02 AM, Nicholas Yue wrote:
> On 13/02/12 6:47 PM, Eric Noulard wrote:
>> 2012/2/13 Nicholas Yue<yue.nicholas at gmail.com>:
>>> Hi,
>>>
>>>     There is an existing project I have access to that already have CMake
>>> configuration file but the way it is written requires alot of preprocessing
>>> steps (python, shell etc) before it is usable.
>>>
>>>     I wanted to investigate a cleaner (truer to CMake original design
>>> purpose) usage of CMake,
>>>
>>>     So, I have an  original-project directory which contains both the source
>>> and the CMakeLists.txt in a nested directory structure.
>>>
>>>     I want to create my own CMake hierarchy (structure the same way) but
>>> reference the source code in the original-project directory location.
>>>
>>>     How do I tell CMake to refer to source code at some other top level
>>> directory as a starting point.
>>>
>>>     Is there such a concept in CMake ?
>> I am not sure to fully understand you request but in a CMakeLists.txt
>> you can perfectly
>> refer to source located outside the directory the CMakeLists.txt is in,
>> you can use either relative or absolute path and do something like:
>>
>> add_executable(NiceTarget ../../relpath/to/source.c
>> ${CMAKE_SOURCE_DIR}/abspath/to/another.c)
> Yes, I know I can do that. I am hoping to avoid maintaining a hierarchy 
> of such modification.
> 
> There are 42 CMakeLists.txt files each with multiple libraries, test and 
> such.
> 
> I was hoping there is a way to (assuming I maintain the same hierarchy) 
> tell CMake to start looking for source from some other top level 
> directory 'once' and it will be able to find the source in the 'other' 
> location that is different to my 'cleaned-up' version of CMakeLists.txt
> 
> Regards
> 
>> this is usually a bad idea but this should work.
>>
>> Now that said if you do that for compatibility purpose in order to
>> maintain the legacy build
>> before doing the switch to "genuine" CMake build then may be using a
>> VCS like git would
>> be a better way to go.
> I have this as a fall back.

You might consider to use your own versions of ADD_EXECUTABLE/LIBRARY()
which modify the source files' paths appropriately; see the following:

FUNCTION(ADD_EXECUTABLE name)
    UNSET(args)
    FOREACH(i IN LISTS ARGN)
        IF(i STREQUAL WIN32
             OR i STREQUAL MACOSX_BUNDLE
               OR i STREQUAL EXCLUDE_FROM_ALL)
            LIST(APPEND args ${i})
        ELSE()
            FILE(GLOB p RELATIVE ${CMAKE_SOURCE_DIR}
                 ${CMAKE_CURRENT_SOURCE_DIR})
            LIST(APPEND args ${EXTERNAL_SOURCE_DIR}/${p}/${i})
        ENDIF()
    ENDFOREACH()
    _ADD_EXECUTABLE(${name} ${args})
ENDFUNCTION()

FUNCTION(ADD_LIBRARY name)
    UNSET(args)
    FOREACH(i IN LISTS ARGN)
        IF(i STREQUAL STATIC
             OR i STREQUAL SHARED
               OR i STREQUAL MODULE
                 OR i STREQUAL EXCLUDE_FROM_ALL)
            LIST(APPEND args ${i})
        ELSE()
            FILE(GLOB p RELATIVE ${CMAKE_SOURCE_DIR}
                 ${CMAKE_CURRENT_SOURCE_DIR})
            LIST(APPEND args ${EXTERNAL_SOURCE_DIR}/${p}/${i})
        ENDIF()
    ENDFOREACH()
    _ADD_LIBRARY(${name} ${args})
ENDFUNCTION()

In this manner, the path of each source file is turned into a full path
pointing into the project's source tree denoted by EXTERNAL_SOURCE_DIR
and respecting the file's location within that tree. Thus, you can set
up a, say, shallow copy of the project, mimicking its directory tree
and populating it only with your adapted CMakeLists.txt files. Note
that this approach would need some refinements, e.g.:

- Be aware of source files generated in the build tree, i.e. check the
  GENERATED source file property and don't modify the path if it's set.

- Be aware of source files with full paths within the project's source
  tree from the first, i.e. check if paths start with CMAKE_SOURCE_DIR
  and replace this prefix with your EXTERNAL_SOURCE_DIR accordingly.

Moreover, note that ADD_EXECUTABLE/LIBRARY() can be overwritten only
once. Personally, however, I would prefer Eric's suggestion to use a
repository managed by a nice branch-capable VCS like Git; IMO, this
will turn out to be much more robust and versatile in the long run.

Regards,

Michael