Digital Filters

Learning Cmake
Pau Garcia i Quiles 
Version 0.4.2 (200811092042GMT+1)

Slides: http://www.elpauer.org/stuff/learning_cmake.pdf

 

 

Part I Build systems – what for?

 

 

Why?
You write an application (source code) and need  to:



Compile the source Link to other libraries Distribute your application as source and/or binary Run tests on your softwareRun test of the redistributable package See the results of that
 







You would also love if you were able to:
 



 

Compiling


Manually?
gcc ­DMYDEFINE ­c myapp.o myapp.cpp



Unfeasible when:


you have many files some files should be compiled only in a particular  platform, are you going to trust your brain? different defines depending on debug/release, platform, compiler, etc
 






 

You really want to automate this step

Linking


Manually?
ld ­o myapp file1.o file2.o file3.o ­lc ­lmylib

Again, unfeasiable if you have many files,  dependence on platforms, etc
 

You also want to automate this step

 

 

Distribute your software


Traditional way of doing things:


Developers develop codeOnce the software is finished, other people package it There are many packaging formats depending on  operating system version, platform, Linux distribution,  etc: .deb, .rpm, .msi, .dmg, .src.tar.gz,  .tar.gz, InstallShield, etc





You'd like to automate this but, is it possible to  bring packagers into the development process?

   

Testing
You all use unit tests when you develop  software, don't you? You should!

When and how to run unit tests? Usually a three­ step process:



You manually invoke the build process (e.g. make) When it's finished, you manually run a test suite When it's finished, you look at the results and  search for errors and/or warnings Can you test the packaging? Do you need to invoke  the individual tests or the unit test manually?
 







 Testing and gathering results
Someone needs to do testing for feach platform,  then merge the results


Is it possible to automate this? “make test”? what  about gathering the results?


 

 

Automate!
Your core business is software development, not  software building
 

What are you selling?


A flight simulator? or, A “flight simulator built with an awesome in­house developed built system”?



 The client does not care about how you built your  software, they are only interested in having the best  software application possible


So should you: modern build systems should be      able to build the software, package it, test it and tell  you if anything went wrong


Part II Build systems tour

 

 

Autotools
It's been in use for many years and it's still widely used


Autohell?
You need to write scripts in Bourne shell ('sh'), m4  (you all develop software in m4, don't you?),  Only Unix platform => Visual Studio, Borland, etc in  Win32 are unsupported (Cygwin/MinGW supported) Dependency discovery is mostly manual (no bundled  “finders” grouping several steps) Usually long, difficult to understand scripts

 

Autotools create a Makefile for 'make' 

Jam
The original implementation (Perforce Jam) is  quite buggy
There are many slightly different implementations

Cross platform Dependency discovery is mostly manual (no  bundled “finders” grouping several steps)


Compiles and links by itself
Users cannot use the tools they are used to What if Jam is not available for that platform?

 

Allows parallel linking

 SCons
Python DSL


The interpreter is not always available You need to learn almost a programming language



Cross­platform You are actually writing a software app which  happens to build another software app


Does not scale well  Dependency discovery is mostly manual (no  bundled “finders” grouping several steps)
    Compiles and links by itself

Waf
...