• # Cross Platform Test Driven Development Environment Using CMake (Part 5)

General and Gameplay Programming

• Posted By Guest
With the release of CMake 2.8.11, some new features have been made available which greatly simplify certain areas of work compared to the prior articles. The primary feature of note is what the CMake documentation calls 'target usage requirements'. In general, CMake now maintains a hierarchy of information about targets, what is needed to not only link them but to also use them from other targets. Previously much of the information required to use a target had to be manually maintained and exported in variables, which was the focus of the prior 4 articles. With the new abilities, I have no problem throwing all that prior work out the door and hopefully once you get through reading this, you won't either. The simplifications to using CMake is impressive and will greatly speed up work with CMake in the future, hopefully this short article will be useful in applying the new feature. Parts 1 2 3 4 5

## New Command Details

Both of the new commands have some details which were ignored for the simple example. For instance, when defining the compile definitions, what are the "PUBLIC" and "PRIVATE" attributes about? There are actually three attributes which the two new commands support, the missing one being "INTERFACE". The concepts are quite easy to grasp in terms of some simple usage examples. Core provides inclusion of GFlags and GLog as part of its job. Unfortunately GFlags and GLog need some special definitions (primarily for Windows) in order to both compile and be used by others correctly. For this purpose, the attribute "PUBLIC" is used to specify the definitions for GFlags and GLog. The public attribute specifies that the definitions exist both when the target itself is being compiled and also when a user of the target is being compiled. The other definition being supplied "BUILDING_CORE" is another Windows-only requirement used only by Core when it is being compiled. It is marked as "PRIVATE" such that it is only defined while Core itself is compiling and any user of the target will not receive the definition. The final unused attribute "INTERFACE" is the opposite of "PRIVATE" in that anything defined after that attribute is not defined while the target is built, it is only defined for users of the target. The same behavior of the definition attributes is used for the include directories. So, for instance, if Core wrapped GFlags instead of exposing it, the include directory for GFlags could be marked "PRIVATE" such that it is only used while compiling Core. Any user of Core that tried to directly include "gflags.h" would have to do the inclusion themselves since it would not be inherited from Core. There are also additional attributes which can be applied to the link libraries but those are mostly special cases which will be ignored. The only real notable attribute is "LINK_PRIVATE" for static libraries which are being placed in shared libraries. Otherwise, the default public linkage is usually appropriate.

## Conclusion

The new CMake release is a welcome simplification to maintaining larger modular projects. The simplification and removal of manual information tracking reduces the verbosity of list files and removes considerable chance for errors. It should be hoped that many projects which use CMake will not hesitate in transitioning to the target usage requirements system and hopefully, if needed, this article will prove useful in making the transition. For the individual user targeting cross platform work, the new release provides even less likelihood of having to deal with difficult to track build problems.

Report Article

## User Feedback

Another great article. If you can add some links to the previous articles, that would be even better.

##### Share on other sites

Oops, was meaning to do that when I moved it from Scrivener, seems I forgotted...  Will fix

##### Share on other sites

These latest cmake features are really great and simplify things a lot.

If anyone's interested, I've created a very simple folder structure with relevant CMakeLists.txt files and sample code that implements most of what's discussed in this series.

Just a note: I mainly work on OSX so this is a bit biased towards clang/libc++

You can check it out at https://github.com/abigagli/CMakeEnvironment

## Create an account

Register a new account