On Monday 29 Jan 2007 IST, Alan W. Irwin wrote: > On 2007-01-29 22:26+0530 kitts wrote: > > # Here I would like SRC_LST to be updated inside the subdir, however, > > # SRC_LST has the complete list in the subdir not changes made are > > # lost as it returns to this parent directory > > ADD_SUBDIRECTORY(${ARCH}) > > > > ADD_LIBRARY(MyLib ${SRC_LST}) > > > > The file Source/x86/CMakeLists.txt only contains: > > > > SET(SRC_LIST ${SRC_LIST} arch.c init.S startup.S) > > > > I don't want to include these files directly in Source/CMakeLists.txt > > as file names and the number of them varies from one arch to another. > > Depending on the complexity, they may further contain subfolders for > > easier code organization. Maintainers of the arch specific are > > different for each arch and id like to let them take responsibility > > with their folders. > > > > The only solution I see is a mechanism in the arch subfolders to create > > a file that will contain names of all the source files for that arch > > and then include that file in the parent folder's CMakeLists.txt. But > > is there a cleaner solution? > > Somebody else mentioned using the cache, but if that doesn't work or you > prefer a different approach, then you could simply use cmake modules to > set SRC_LST for each of your possible architectures and then INCLUDE the > appropriate architecture module when needed. That's the approach PLplot > takes when configuring source lists (for various device drivers in our > case rather than various architectures as in your case). We have a fixed > module directory for our modules (cmake/modules), but you could configure > CMAKE_MODULE_PATH to point to the appropriate architecture dependent > module directory as needed if you prefer to keep your architectures in > totally separate directories.
I could use this approach as well. I just wanted to leave the responsibility to the arch maintainer. This is still a viable option. > BTW, my understanding of why variables set in subdirectories do not > propagate to parent directories is the CMake developers are using this > rule to (rightly) limit variable scope to make it more difficult to have > cross-directory bugs. I agree it's the right way. Its pass-by-value but i also wanted the option of a pass-by-reference when one knows exactly what he/she is doing. ;-) -- Cheers! kitts _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake