On 12/03/2010 04:26 PM, Raymond Wan wrote: > Hi Michael, > > Thank you for your continued advice! > > > On Fri, Dec 3, 2010 at 19:13, Michael Hertling <mhertl...@online.de> wrote: >> Nevertheless, I wonder why you want to build "main" by configuring its >> own source directory and alternatively via the top-level directory. If >> this is because you'd like to exclude some modules from building, you >> should handle such things in the top-level CMakeLists.txt, e.g. like: >> >> # Define options: >> OPTION(WITH_MAIN "Build module main" ON) >> OPTION(WITH_A "Build module A" ON) >> OPTION(WITH_B "Build module B" ON) >> >> # Handle dependencies: >> IF(WITH_MAIN) >> SET(WITH_A ON) >> ENDIF() >> >> # Enable modules: >> IF(WITH_B) >> ADD_SUBDIRECTORY(dir-B) >> ENDIF() >> IF(WITH_A) >> ADD_SUBDIRECTORY(dir-A) >> ENDIF() >> IF(WITH_MAIN) >> ADD_SUBDIRECTORY(main) >> ENDIF() >> >> So, you can conveniently enable/disable the modules on the command line >> or in the GUI, e.g. with "cmake -DWITH_B=OFF <path/to/top-level-dir>" >> if you don't want to build module B. >> >> As an alternative, you might consider to move dir-A to main/dir-A if >> dir-A is essentially a submodule of main, but referring to a sibling >> dir-A from main indicates that the latter is not sufficiently self- >> contained to be built on its own with a "cmake <path/to/main>", so >> the modules' relationships should be handled by other means, IMO. > > > Hmmmmm, I see your point about why I'm providing support in a > top-level CMakeLists.txt and a lower level one. Perhaps I've simply > confused myself and made things more complicated than it needs to be. > Basically, what I want to do is, given this directory structure: > > myproj/ > +dirA/ > +dirB/ > +dirC/ > +main1/ > +main2/ > +main3/ > > my final goal is that several programs (i.e., executables) will be > made. Let's say main1, main2, and main3. The libraries dirA, ..., > dirD are used by them and can also depend on each other with maybe > even multiple levels of dependencies. i.e., > > dirA --> dirB --> dirC > > Any of these modules can be used by more than one program. i.e., > > main1 --> dirA --> dirB --> dirC > main2 --> dirC > > My idea is that the top level CMakeLists.txt can create main1, main2, > and main3. The lower level CMakeLists.txt in dirA/, dirB/, and dirC/ > have their own main () which I am using to test them -- obviously, > these main () functions are not linked into main1, main2, and main3. > I only need them for development. I think organizing dirA/, dirB/, > and dirC/ within main1/, main2/, and main3/ isn't the way to go since > these libraries are used by multiple executables.
Yes, absolutely, with such relations among executables and libraries, their source directories should be siblings instead of descendants, and the libraries' testing executables can be conveniently integrated using ADD_TEST() without interfering with the main executables. However, when your project grows and, hence, the number of source directories in the project's root increases, say 10+, you should consider to organize them further, e.g. like myproj executables main{1,2,3,...} libraries dir{A,B,C,...} plugins ... or myproj source core ... gui ... db ... or whichever organizational criteria apply best, so the root directory doesn't fill with countless source directories. Apart from that, there is no need to have the top-level CMakeLists.txt create the main{1,2,3} executables by itself; just add a CMakeLists.txt file in each of their source directories as you do for the libraries, and use ADD_SUBDIRECTORY(main1) ADD_SUBDIRECTORY(main2) ADD_SUBDIRECTORY(main3) at the top level to enable them. In this way, you've a CMakeLists.txt file in each of your project's source directories which does exactly what needs to be done there, and the whole project is covered by the top-level CMakeLists.txt with minimal assumptions w.r.t. the source directories. > Perhaps I should create and use the low-level CMakeLists.txt and when > I am finished development, then create the top-level ones for just > main1, main2, and main3. In a way, I will only need to support either > the top-level CMakeLists.txt or the lower level one and never both at > the same time. I guess I am ahead of myself and did both now, which > is complicating things for me. IMO, there is no reason to configure with lower-level CMakeLists.txt files at first and switch to a top-level CMakeLists.txt later. Instead, start right away with one CMakeLists.txt file per source directory and one top-level CMakeLists.txt, and whenever a new source directory with its own CMakeLists.txt is added to your project, just add an according ADD_SUBDIRECTORY() at the top level, too. So, you will always have a clean and regular configurational setup without the need to bother with different starting points for configuring your project. > Hmmmm, I need to give this a bit more thought -- any suggestions > welcome... Thank you! Regards, Michael _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake