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. 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. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
