I wrote about using CPack to create a make dist target earlier today, but it turns out there is a much simpler way to do this, thanks to Christophe Fergeau for pointing me to it.
Note that this won’t work if your project is not using a version control system (but if you are not, then you are asking for trouble!).
Here are the necessary lines to add to your CMakeLists.txt file if your project is using Git:
set(PROJECT_VERSION "0.2.3")
set(ARCHIVE_NAME ${CMAKE_PROJECT_NAME}-${PROJECT_VERSION})
add_custom_target(dist
COMMAND git archive --prefix=${ARCHIVE_NAME}/ HEAD
| bzip2 > ${CMAKE_BINARY_DIR}/${ARCHIVE_NAME}.tar.bz2
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
If your project uses Bazaar, replace the “add_custom_target” line with:
add_custom_target(dist
COMMAND bzr export --root=${ARCHIVE_NAME}
${CMAKE_BINARY_DIR}/${ARCHIVE_NAME}.tar.bz2
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
If you know how to do this with another version control system, please add a comment!
My comment to your previous blog post was mostly a tongue in cheek comment since cmake makes some things really complicated while you get them for free with the autotools… Hardcoding the SCM used in make dist is imo a bad thing, for example if someone wants to use a git2xxx gateway, this make dist target won’t work for him for obvious reasons. Ditto for all the projects which are switching from svn to git nowadays.
Don’t get me started on autotools… I consider them to be one of the biggest if not the biggest error the free software community created. All build systems suck more or less, but only autotools can make you cry in despair. Only autotools requires you to use a two-level generation system (Makefile.in, then Makefile) and a scripting language (M4) so useless you need to write almost everything in shell.
> cmake makes some things really complicated while you get them for free with the autotools…
True, CMake does not come with a “dist” target out of the box, but the few lines I described in my previous blog make it possible to create .msi, .dmg, .rpm or .deb… does autotools give you this for free?
> Hardcoding the SCM used in make dist is imo a bad thing
Using the SCM to track which files should be included in the distribution sounds much saner to me than having to declare those files manually.
It means a source distribution is a snapshot of what you have in the repository. It’s just not a good idea with autotools because autotools require you to ship auto-generated files (the ./configure and its Makefile.in friends). Since they are auto-generated, you do not want to commit them in your repository, thus creating the need for a parallel way to declare which files should be releases. Other build system like CMake or SCons do not have such requirements, making the maintainer life easier.
The main purpose of the autotools is to make the life of the *users* easier and to add portability to the generated Makefile. In the long run autotools make the maintainer life easier, too.
The purpose of cmake is to make the life of the maintainer easier at the expense of portability, cross-build-ability and extra dependency during build.
As long as cmake is not ported to my target platform cmake is useless while autotools *results* are definetly more portable than cmake itslef.
The goal of autotools is nice, unfortunately I think the way it was implemented is a pain.
I am curious, what is your target platform?
I wasn’t actually talking about some platform in which I have a special interest and cmake wasn’t there, but it always fascinated me how autotools had support for flavours of Unices I heard and/or had brief contact with and thought the platform was lacking (e.g. AIX).
Using the autotools makes porting to that platform easy and thus enriching it easily.
OTOH, when I looked the last time at it, cross building in cmake was not possible. This is problematic for slower arches such as ARM, AVR32 since native building is almost in all cases out of the question. Not sure what’s the current situation, but taking into account the design of the tool, that seems difficult (but I might be wrong).
Cross building is much better starting with cmake 2.6, but nowadays it’s probably easier to use scratchbox or openembedded for your cross build needs. This applies to both autotools or cmake based projects (been there, done that)