[CMake] behavior of SUBDIRS changed

[Bradley Lowekamp]

That is exactly what the problem was. I was doing (I have not run this):

Parent CMakeLists.txt file
-------------------------------

SUBDIRS(dir1 dir2)

ADD_LIBRARY(mylib "${DIR1_SRC_FILES} ${DIR2_SRC_FILES}")

Dir1 file
-----------------------------------
SET(DIR1_SRC_FILES "dir1.cpp" CACHE STRING "test")


This does not look as illogical as your example;  in this case it 
seemed to made sense. I am in the progress of now moving to the 
ADD_SUBDIRECTORY method, but with this I need to reorder my settings so 
that the children have the right options (ie. include directories 
etc.), and I am loosing backwards compatibility (not a big issues when 
the release comes out). It appears I was quite dependent on the 
multiple passes of the way things were previously implemented.

Thanks for explaining to me what was going on!

On Jun 10, 2005, at 12:51 PM, Ken Martin wrote:

> I don't think SUBDIRS has changed in behavior. The implementation has
> changed so maybe there is a problem but there should not be a behavior
> change to my knowledge.  Let me know if you narrow it down. SUBDIRS 
> still
> get handled at the end of the parent list file and cache variables from
> subdirs still populate the cache as usual. The difference you may be 
> seeing
> is that in the past each subdir re-traversed its parent's list file so
> essentially a subdir could get different variable settings from what 
> the
> parent CMakeLists file received.  For example
>
> Parent CMakeLists.txt file
> -------------------------------
> IF (SUB1)
>   SET(BAR)
> ENDIF (SUB1)
>
> SUBDIRS(dir1 dir2)
>
>
> Dir1 file
> -----------------------------------
> SET(SUB1 1 CACHE STRING "test")
>
>
> Dir2 file
> -----------------------------
> IF(BAR)
>   MESSAGE ("only see with CMake 2.0")
> ENDIF(BAR)
>
>
> In CMake 2.0 bar would be set for dir2 on the first configure because 
> the
> parent list file is reprocessed for each subdirectory recursively 
> (slow and
> confusing) In Cmake 2.2 whatever the value of BAR is at the end of the
> parent makefile is what it will be for all the subdirs. So for the 
> first
> configure it will not be set, for subsequest configures (when SUB1 is 
> in the
> cache) it will be set. I'm not sure if this has anything to do with 
> your
> issue but that is the only difference I know about. In CMake 2.2 you 
> can
> actual do something like this using ADD_SUBDIRECTORY for example write 
> the
> parent CMakeLists.txt file as:
>
> # process dir1 now so that it can add cache entries
> ADD_SUBDIRECTORY(dir1)
>
> # did it add the cache entry
> IF (SUB1)
>   SET(BAR)
> ENDIF (SUB1)
>
> # process dir2 with a current value of BAR
> ADD_SUBDIRECTORY(dir2)
>
>
>
> Thanks
> Ken
>
>
>
>> -----Original Message-----
>> From: cmake-bounces+ken.martin=kitware.com at cmake.org [mailto:cmake-
>> bounces+ken.martin=kitware.com at cmake.org] On Behalf Of Bradley 
>> Lowekamp
>> Sent: Friday, June 10, 2005 11:20 AM
>> To: 'CMake Mailing List'
>> Subject: [CMake] behavior of SUBDIRS changed
>>
>> I believe that I just encountered a change in the behavior of SUBDIRS.
>> I was using a version from december and I am now using a version from 
>> a
>> few days ago. Is  there suppose to have been a change in behavior? 
>> that
>> wold seem like a very bad thing to me. I might be able to narrow down
>> the case to a small example if needed, but that wold take some time.
>>
>> The change seems to have to do with when the subdirectories get
>> traversed and how when the subdirectories cache variable effects the
>> parents variable.
>>
>> Thanks
>>
>> ========================================================
>> Bradley Lowekamp
>> Management Systems Designers Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine
>> 'blowekamp at mail.nih.gov
>>
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>