kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

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.

Dick