Home > CMake, WkCMake > WkCMake and building differences on different platforms

WkCMake and building differences on different platforms

I recently had a lot of troubles with compilation, linking and other related stuff, even more difficult on cross platform environments (  reminder, we are talking C++ here…)

Those who know me know that I like CMake a lot because it an generate build environment for many different kinds of platform. However I ended up writing my own wrapper of CMake, just to make things even easier, and probably more adapted to the way I write code and architecture software…

This Project is hosted on GNA, with a BSD license and called WkCMake. Its purpose is basically to automate as much build steps as possible, even between different projects, and that on different platforms. A bit like source-based package managers are doing on Unix based platforms, using autotools as build framework… Everyone interested in this field will know how much Windows can be different, but since I am interested in Video Games and Windows is a very widely used platform for this type of applications, I have to make that build framework work painlessly even on Windows…

To give a quick overview of the problem, when you are working on a project you have:
– main target ( can be library or executable )
– tests target ( can be unit tests, depending on the main target or just simple piece of code to try something out quickly )

That project can depends on other projects, already built using the same framework, but maybe not installed.

And each project in that hierarchy can have external dependencies, installed on the system, that are easily detected on unix-type platform using CMake or autotools, but not so easily on windows. But I wont talk about installed dependencies for now, this will be another story…

Each project can be built with a huge set of possible options, usually grouped in “configurations”, such as “Debug”, “Release”, etc.
So I recently had to decide which strategy to employ when building multiple projects together. The problem being that each project has to be able to autodetect which projects it is dependent on, and which configuration of the dependencies it should be using, for compilation ( includes ), for linkage ( libraries ), and for execution ( dynamic libraries, .so, .dll, etc. )

So if I have a dependency chain such as A -> B -> C ( A depends on B who depends on C ) I want:
– C built in a certain configuration conf1,
– B building in a configuration conf2, and detect C, its configuration and the proper way to link it, and copy C’s dynamic libraries if needed. Also declaring C as a dependency for A.
– A building in a configuration conf3. A must find B and see that B requires also C, and then detect B and C configurations, linkage properties, and dynamic libraries for copy.

This is a pretty complex problem to do on a multiple platform scale ( one platform for one hierarchy ), with multiple configurations ( in the same hierarchy ). The convenient thing for the user is to propose only the configuration that are compatibles and useful with the dependencies’ configurations. I am not an expert in linkage programs, but as far as I am aware there is no automated way of seeing if a compilation option can be linked to another properly, and therefore it would be to the user to decide that he wants this configuration link to this one. That wouldnt probably be really useful to someone who just wants to get stuff done, and build it.

Also CMake already propose a scheme for that, in its “target link-dependencies” system. As of CMake 2.8 ( like in 2.6 ), that scheme is : same configuration for all linked libraries, ie conf1 = conf2 = conf3. That is if my main target is built in “Debug” configuration, I expect my dependencies to be built in “Debug” configuration as well.

Reusing CMake scheme, it would mean for us : A(“Release”) -> B(“Release”) -> C(“Release”) OR A(“Debug”)->B(“Debug”)->C(“Debug”)

Of course a user might want a A(“Release”)->B(“Debug”)->C(“Release”) build if he wants to debug only B.

But is this really useful ? How can we make sure that the link will happen properly, no matter which platform or compiler we will use ?
The set of target system is too huge to test extensively, so I decided to rely on CMake system, meaning that your whole project hierarchy will have only one possible configuration.

One can say that kind of kills the purpose of having multiple projects, but one other can reply that C can be properly done and installed , B can use it as an external dependency, and B can be tested and debugged on its own. Afterall thats why tests programs are for in each projects, and that can be another purpose for having multiple projects : more tests…

Therefore simpler is probably better.

Advertisements
Categories: CMake, WkCMake Tags: , , , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: