[CMake] Re: How to update a variable inside a subfolder?

kitts kitts.mailinglists at gmail.com
Mon Jan 29 14:50:29 EST 2007


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


More information about the CMake mailing list