Developing with CMake

[Nexus]

Hello, I have a rather general question concerning CMake. I often hear it simplifies things, for developers as well as for users. I understand, that when CMake is correctly configured, it can be used for a large amount of compilers and IDEs.

But until one can configure it correctly to support a wide range of compilers, it seems to be a real pain, especially in the beginning. I've been surprised a little bit by the big amount of script and config files required for CMake just to generate SFML. Besides, a lot of cases (e.g. VS or g++) are still differentiated manually, while CMake promises to relieve developers of exactly this process. The recent quotation mark issue shows me that there are still several things that don't work as expected (maybe I should inform the CMake team about that).

I have considered using CMake to build own libraries in the future, but at the moment I'm rather sceptical. Also I would have to learn the CMake script language...

What is your experience (Laurent and other people using CMake to build own projects)?

[ratzlaff]

Once it is set up and you have built for multiple platforms, then it is awesome for rapidly building/testing for all platforms simply because there is one source list that generates all targets.

Does it have a learning curve for setting up the first time? yes
Is it worth the pain? I believe so

[Laurent]

My CMake scripts are rather huge and complicated because I do silly things with static build on Windows -- basically emulating the linking step that doesn't normally happens.

Apart from that, CMake is pretty cool for "regular stuff" in my opinion. At work we use it intensively and I don't know how we would do without it, as every developer has its own OS and compiler. And so far there's nothing that I couldn't do with CMake, it's complete and it let you customize things that are not implemented "directly".

I thinks this is the best solution if you plan to distribute an open-source multi-platform library. Simply because you can't write a makefile/project for every possible OS and compiler, and there will always be someone asking for it.

[Nexus]

oes it have a learning curve for setting up the first time? yes
Is it worth the pain? I believe so

So maybe I should try it when I have the time. How long do you think will it need to get the first projects working, roughly speaking? I only know how to use a given CMake configuration (but even that only partially).

My CMake scripts are rather huge and complicated because I do silly things with static build on Windows -- basically emulating the linking step that doesn't normally happens.

When I develop for windows and allow static building, don't I have to do something similar? Or in how far is that SFML-specific?

I thinks this is the best solution if you plan to distribute an open-source multi-platform library. Simply because you can't write a makefile/project for every possible OS and compiler, and there will always be someone asking for it.

Okay. Yeah, the alternative would be to support the mostly used compilers, but that's probably not the best solution. However it seemed to work in SFML for quite a long time (but I know that it put a big effort on you).

[Laurent]

When I develop for windows and allow static building, don't I have to do something similar? Or in how far is that SFML-specific?

Normally you don't link external dependencies when you statically build your library, and this is true for all OSes and compilers (a static library is just an archive of object files).
I do so in SFML because I don't want users to have to link against libjpeg, opengl, openal, libsndfile, etc. when using SFML static libraries.

Okay. Yeah, the alternative would be to support the mostly used compilers, but that's probably not the best solution. However it seemed to work in SFML for quite a long time (but I know that it put a big effort on you).

It didn't really work. My Linux makefiles were not 100% correct, some users complained about the lack of Msys/MinGW makefiles on Windows, as well as gcc makefiles on OS X, there was no support for VC++ 2010, and no support at all for 64 bits builds.

[Nexus]

Normally you don't link external dependencies when you statically build your library, and this is true for all OSes and compilers (a static library is just an archive of object files).

In my opinion, it matters how the external dependencies are used. If they are just for library-internal usage (like libjpeg etc. for SFML), it's appropriate for link them on library side. But when a library is built on top of another existing library to extend the latter (e.g. a SFML extension), I think it's okay not to link anything, since the user is doing it anyway.

Would you agree with this, or do you recommend not to link dependent libraries in general? And what about dynamic libraries?

[Laurent]

Would you agree with this, or do you recommend not to link dependent libraries in general? And what about dynamic libraries?

Of course I agree, but the truth is that static libraries can't link to other libraries and you have to find ugly, compiler specific hacks to work around that limitation.
I don't know if many libraries use this kind of hacks; maybe they simply don't allow static build.

On Linux, I know that some libraries use pkg-config to hide the correct linker options behind a simpler command line argument.

gcc `pkg-config ––libs sdl` test.c -o test

Dynamic libraries don't suffer from this limitation, since they can link to other libraries.

[Nexus]

Okay, I didn't know of those limitations.

Thanks a lot for your answers, ratzlaff and Laurent! Other opinions are still welcome