Alan, Thank you for such a detailed response. I am pretty new to this mailing list and have only responded to a few questions on here, but I have really thought the responsiveness on here is the best of any of the message boards that I belong to and I really appreciate it, so I like to give back as well.
Anyway, the project that I work on is not your typical application. It is a framework and a couple of applications built off of the framework. Each of the applications have a pluggable interface that outside organizations use to build their own plugins/modules that work together to form the End-User Application. We do not actually develop for users, we develop for developers. So, I may be way off base, but when developing this I decided to follow a structure like below: ------------ src/CMakeLists.txt project(OurFramework) add_subdirectory(CoreModule1) add_subdirectory(CoreModule2) add_subdirectory(CoreModule3) add_subdirectory(CoreModule4) ------------- End File And then in each of the core module's directory, they would have their own list file like so: ------------- src/CoreModule1/CMakeLists.txt project(CoreModule1) include(CommonConfigurationFile) ... # Add the files here and the stuff specific to this module. -------------- End File The above is how the core framework is structured. The pluggable applications have a similar structure except that the top-level is not necessarily all of the plugins/modules for the entire application, it may be just a subset. There are ~100 plugins that we develop internally and who knows how many externally. I would love your opinion on what I have done here. Since this being developed for developers, it is always nice to get the developer's (our end-user's) perspective. Do you think I am missing the purpose of the project() command all together? Thanks, Eric > -----Original Message----- > From: Alan W. Irwin [mailto:[email protected]] > Sent: Monday, October 22, 2012 1:58 PM > To: Eric Clark > Cc: Rolf Eike Beer; [email protected] > Subject: CMake-based build systems that are useful for study purposes? > > On 2012-10-22 17:55-0000 Eric Clark wrote: > > > Awesome! Thank you for the answers and the quick reply! I have only > been using CMake for a little over a year and again I am sorry for posting an > incorrect answer. I always thought that I had to have one > project() call for each add_executable and/or add_library. It is very good to > know that that is not the case. However, I am curious if you think it is good > practice to do such a thing? > > To join this conversation late, but to give it a new twist with a new subject > line it is typical practice to have one project() call (done in the top-level > CMakeLists.txt file) for each software project (e.g., a complete source tree > that is typically distributed as an independent > tarball) no matter how many libraries and executables are built for that > project. > > When I first learned CMake years ago I looked at a number of projects with > CMake-based build systems to see what was typical usage, and I suggest you > might want to do the same. > > I used to advocate studying the CMake-based build system for PLplot that I > helped to implement, but that was essentially done so many years ago > (although it is still maintained extensively) that I am sure there are much > better best practices out there now especially considering all the additional > useful CMake features that have been introduced over the years. > > I initially did a lot of my learning based on the CMake-based build systems > for > CMake itself and also for KDE so one of those might be worthy studying now, > but they also might have the same problem (too many years of history > without necessarily keeping up with best > practices) that PLplot does. > > Are the CMake and KDE build systems still the best paradigms for study or > are there better ones for study that can be recommended now? > > 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); the Time Ephemerides project > (timeephem.sf.net); PLplot scientific plotting software package > (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux > Links > project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ -- 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
