[CMake] CMake-based build systems that are useful for study purposes?

[Eric Clark]

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:irwin at beluga.phys.uvic.ca]
> Sent: Monday, October 22, 2012 1:58 PM
> To: Eric Clark
> Cc: Rolf Eike Beer; cmake at cmake.org
> 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
> __________________________