[CMake] source_group(): Which project is it added to?

[cyril_wobow]

Robert Dailey a écrit :
> On Mon, Dec 1, 2008 at 10:52 AM, cyril_wobow <cyril at wobow.com 
> <mailto:cyril at wobow.com>> wrote:
>
>     It's my understanding that you are trying to declare two
>     "solutions" p1 and p2 (using visual studio's terminology).
>     The source_group() calls affects the next "project" declaration
>     (which is done with add_executable() or add_library()) in the
>     cmake module where they occur .
>
>
> That is indeed how I would expect it to work, but that's not what is 
> happening. Below is the actual CMake code I'm using to generate projects:
>
> macro( component project_name )
>     cmake_minimum_required( VERSION 2.6 )
>     set_include_directories()
>     add_definitions( -DBOOST_ALL_NO_LIB )
>    
>     if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/test )
>         project( ${project_name}_test )
>         file( GLOB_RECURSE testsrc test/*.[chi]pp )
>         add_executable( ${project_name}_test ${testsrc} )
>     else()
>         message( "WARNING: No unit test found for component 
> vfx/${project_name}" )
>     endif()
>    
>     project( ${project_name} )
>
>     file( GLOB_RECURSE inc RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} 
> include/*.[chi]pp )
>     file( GLOB_RECURSE src RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} 
> source/*.[chi]pp )
>    
>     foreach( file ${inc};${src} )
>         get_filename_component( path ${file} PATH )
>         string( REPLACE / \\ group ${path} )
>         source_group( ${group} FILES ${file} )
>     endforeach()
> endmacro()
>
> macro( library_component project_name )
>     component( ${project_name} )
>     add_library( ${project_name} STATIC ${inc};${src} )
> endmacro()
>
> Inside of another CMakeLists.txt file in a different subdirectory, 
> I'll call *library_component( ProjectName )*. Is this a bug in CMake 
> or am I just doing this incorrectly? Help would be appreciated! Thank you.
I remember an issue (still pending) where the PROJECT() macro would have 
to be invoked from within the root CMakeList file. This problem occured 
to me  while writing my homemade macros and I had to work it around by 
splitting my macro in half and having the following in my root CMakeList 
file :
MYMACRO1(...)
PROJECT(xxx)
MYMACRO2(...)
... which is ugly and could really use a fix.