← Back to team overview

kicad-developers team mailing list archive

Re: CPack integration for crossplatform creation of binary and source archives -- patch


On Sat, Jul 31, 2010 at 4:19 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> Jerry,
> Some questions below:
>> Dear all,
>> As I was trying to find a neat way to create mac packages on the fly I
>> bumped to CPack. This application is shipped with CMake and can be used
>> inside the existing CMakeLists.txt configuration. For mac I enabled for
>> now only DragNDrop packages which are like zip archives instead of
>> full-fledged PackageMaker installers. The most neat thing is it creates
>> the archives by itself without using any external script or utility.
>> Then the packaging/mac-osx/dmg-generator directory can be removed from
>> the source-tree if this patch is applied.
>> If you look deeper at CPack or CMake CPack module it also integrates
>> generation of NSIS installer for windows and self-extracting shell
>> script for *NIX. This takes us a whole bunch of work from our hands if
>> other people want to do snapshots/nightly builds or actual releasing the
>> software.
>> A console output on my mac when creating source archives (make sure you
>> do a out of source build or else all the CMake cache stuff will also be
>> in the source archive!)
>> white:darwin jerry$ sudo make package_source
>> Run CPack packaging tool for source...
>> CPack: Create package using TGZ
>> CPack: Install projects
>> CPack: - Install directory: /Users/jerry/Work/kicad/repository
>> CPack: Compress package
>> CPack: Finalize package
>> CPack: Package
>> /Users/jerry/Work/kicad/build/darwin/kicad-2010.07.23-Source.tar.gz
>> generated.
>> When creating binary package(s) which can be selected with the
>> CPACK_GENERATOR variable they can be build with the *make package* command.
>> For more information see cmake --help-module CPack
>> I attached the main CMakeLists.txt patch. Only maybe other people have
>> a suggestion to extract the date from BZR or system when building
>> instead of changing the 3 variables BUILD_ YEAR, MONTH, DAY.
> I think we can assume:
> 1) Those who would use cmake to build Kicad also have BZR installed.
> 2) Those who would use BZR also have python installed.
> Therefore we can assume python at a version necessary to run BZR is
> installed within the CMakeLists.txt script, but may not be in the PATH.
> Could someone (you?) write a simple python "eval" type statement to get
> these strings?  Then we can use a CMake macro to chain load python for
> such values.

I have zero experience with Python programming, and I have time to learn
it. Maybe somebody else with experience can have a look at it. And why are those
things not handled with CMake itself in form of Variables?

> Here was somebody doing something similar with perl:
> http://osdir.com/ml/programming.tools.cmake.user/2006-06/msg00323.html
> I would see no harm in enabling other CPack "targets" for CMake, as long
> as they did not unconditionally fire when running CMake.  The Doxygen
> target is one such optional cmake target.

Those package and package_source targets don't break the normal behavior.
So adding those for every major platform like *Win, *NIX, Mac should not be a
big deal.

It was just that it is much easier for me to build a DMG/Zip on OSX with CPack
than some hacked scripts and utilities. And this would also count for windows
and linux. Then we have more possibilities and everything is configured from
one file, and all the rest is handled by CPack.

Follow ups