https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Tshead&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T11:23:29ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=VTK/Array_Refactoring&diff=14988VTK/Array Refactoring2009-04-10T14:42:34Z<p>Tshead: New page: == Overview == Now that we have [http://kitware.com/InfovisWiki/index.php/N-Way_Array_Data_Structures N-Way Array Data Structures], it would be ideal if we could use them as attributes in...</p>
<hr />
<div>== Overview ==<br />
<br />
Now that we have [http://kitware.com/InfovisWiki/index.php/N-Way_Array_Data_Structures N-Way Array Data Structures], it would be ideal if we could use them as attributes in data objects. This will likely involve some tricky work to somehow merge the vtkAbstractArray- and vtkArray- hierarchies.<br />
<br />
== Recent Work ==<br />
<br />
* Merged vtkFactoredArrayData / vtkFactoredArrayDataAlgorithm into vtkArrayData / vtkArrayDataAlgorithm.<br />
<br />
* Added vtkArray::GetName() and vtkArray::SetName().<br />
<br />
* vtkDenseArray memory management.<br />
** vtkDenseArray::MemoryBlock.<br />
** vtkDenseArray::StaticMemoryBlock.<br />
** vtkDenseArray::HeapMemoryBlock.<br />
<br />
* vtkSparseICSArray.<br />
** Changes the way coordinates are stored, one contiguous array of coordinates per dimension, instead of a single contiguous array for all dimensions.<br />
** Implements value sorting.<br />
** Could probably replace the current vtkSparseArray implementation.<br />
<br />
== Proposed Work ==<br />
<br />
* Provide iterators, memory layout functionality in vtkDenseArray to support in-situ work.<br />
* Support vtkArray as attributes. Some different approaches:<br />
*# vtkArray derives from vtkAbstractArray.<br />
*#* Worst possible approach, there are methods in vtkAbstractArray (GetVoidPointer()) that are totally incompatible with sparse arrays.<br />
*# vtkArray and vtkAbstractArray remain apart.<br />
*#* vtkFieldData would store vtkArray as a distinct type. Unfortunately, GetArray() is already taken by vtkDataArray.<br />
*#* vtkAbstractArray derivatives HAVE-A vtkDenseArray to eliminate duplicate implementations.<br />
*# vtkAbstractArray derives from vtkArray.<br />
*#* Implementing vtkArray in current vtkAbstractArray implementations should be straightforward.<br />
*#* vtkFieldData would have to provide methods that return vtkArray. Same problems with GetArray().<br />
*#* Implies changes to Get/SetInputArrayToProcess().<br />
<br />
== Action Items ==<br />
<br />
* Performance comparisons between vtkDataArray & vtkDenseArray (Tim Shead)<br />
* Modify vtkAbstractArray to provide access to an (optional) underlying vtkArray (Tim Shead)<br />
* Modify vtkDataArray to use vtkDenseArray as an implementation (Andy Bauer?)<br />
* Update vtkFieldData and vtkDataSetAttributes APIs to support vtkArray directly (Andy Bauer?)<br />
* Deprecate vtkAbstractArray and its derivatives (Brian Wylie)</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=VTK&diff=14987VTK2009-04-10T14:41:48Z<p>Tshead: /* Current Projects */</p>
<hr />
<div>http://public.kitware.com/images/logos/vtk-logo2.jpg<br />
<br /><br />
The Visualization ToolKit (VTK) is an open source, freely available software system for 3D computer graphics, image processing, and visualization used by thousands of researchers and developers around the world. VTK consists of a C++ class library, and several interpreted interface layers including Tcl/Tk, Java, and Python. Professional support and products for VTK are provided by Kitware, Inc. ([http://www.kitware.com www.kitware.com]) VTK supports a wide variety of visualization algorithms including scalar, vector, tensor, texture, and volumetric methods; and advanced modeling techniques such as implicit modelling, polygon reduction, mesh smoothing, cutting, contouring, and Delaunay triangulation. In addition, dozens of imaging algorithms have been directly integrated to allow the user to mix 2D imaging / 3D graphics algorithms and data.<br />
<br />
==Example Usage==<br />
* [[Which Libraries Do I Link To?]]<br />
* [[Which Header Files Do I Include?]]<br />
* [[Classes To Help With Examples]]<br />
* [[Write a VTP file]]<br />
* [[Read a VTP file]]<br />
* [[Write a VTU file]]<br />
* [[Read a VTU file]]<br />
* [[Write a file of the four corners of a square]]<br />
* [[Write a file of a triangulated square]]<br />
* [[Write a file of the four corners of square, each with a different color]]<br />
* [[Write a file of a triangulated square, each corner with a different color]]<br />
* [[Write a file of a triangulated square, each triangle with a different color]]<br />
<br />
==Administrative Topics==<br />
<br />
* Where can I find more [[VTK Additional Information|information about VTK]]?<br />
<br />
* [[VTK 5.4 Release Planning]]<br />
<br />
* Where can I [http://vtk.org/get-software.php download VTK]?<br />
<br />
* Where can I download a tarball of the [http://vtk.org/files/nightly/vtkNightlyDocHtml.tar.gz nightly HTML documentation]?<br />
<br />
* [[VTK Classes|Extending VTK]]<br />
<br />
* [[VTK Coding Standards]]<br />
<br />
* [[VTK cvs commit Guidelines]]<br />
<br />
* [[VTK Scripts|Extending VTK with Scripts]]<br />
<br />
* [[VTK Tools|VTK-Based Tools and Applications]]<br />
<br />
* What are some [[VTK Projects|projects using VTK]]?<br />
<br />
* [[Proposed Changes to VTK | Proposed Changes to VTK]]<br />
<br />
* [[VTK FAQ|Frequently asked questions (FAQ)]]<br />
<br />
* [[VTK OpenGL|Common OpenGL troubles]]<br />
<br />
* [[VTK Related Job Opportunities|VTK Related Job Opportunities]]<br />
<br />
* [[VTK/Writing_VTK_files_using_python | Writing VTK files using python]]<br />
<br />
* [[VTK/mesh quality | Geometric mesh quality]]<br />
<br />
* [[VTK_XML_Formats | VTK XML Format Details]]<br />
<br />
* [[VTK_Third_Party_Library_Patrol | VTK 3rd Party Library Patrol]]<br />
<br />
== Current Projects ==<br />
* [[VTK/Java Wrapping | VTK Java Wrapping]]<br />
* [[VTK/Composite Data Redesign | Composite Data Redesign]]<br />
* [[VTKWidgets | VTK Widget Redesign]]<br />
* [[VTKShaders | Shaders in VTK]]<br />
* [[VTK/VTKMatlab | VTK with Matlab]]<br />
* [[VTK/Time_Support | VTK Time support]]<br />
* [[VTK/Depth_Peeling | VTK Depth Peeling]]<br />
* [[VTK/MultiPass_Rendering | VTK Multi-Pass Rendering]]<br />
* [[VTK/Using_JRuby | Using VTK with JRuby]]<br />
* [[VTK/Painters | Painters]]<br />
* [[VTK/Cray XT3 Compilation| Cray XT3 Compilation]]<br />
* [[VTK/statistics | Statistics]]<br />
* [[VTK/Array Refactoring | Array Refactoring]]<br />
<br />
== External Links ==<br />
*[http://www.imtek.uni-freiburg.de/simulation/mathematica/IMSweb/ IMTEK Mathematica Supplement (IMS)], the Open Source IMTEK Mathematica Supplement (IMS) interfaces VTK and generates ParaView batch scripts<br />
*[http://zorayasantos.tripod.com/vtk_csharp_examples], VTK examples in C# (Visual Studio 5.0 and .NET 2.0)<br />
{{VTK/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13953CMake:CPackPackageGenerators2008-11-02T03:24:10Z<p>Tshead: /* Overview */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged using the bundle-generator! Specifying MACOSX_BUNDLE creates a separate bundle for each individual executable at build-time; the structure of these bundles becomes redundant when the bundle generator consolidates multiple executables into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
* Provide an option or alternative to CPACK_BUNDLE_STARTUP_COMMAND that simply executes one of the files installed in the bundle. Presumably, this should be a symlink to a binary or script.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13945CMake:CPackPackageGenerators2008-10-30T19:12:18Z<p>Tshead: /* TODO */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged by the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
* Provide an option or alternative to CPACK_BUNDLE_STARTUP_COMMAND that simply executes one of the files installed in the bundle. Presumably, this should be a symlink to a binary or script.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13942CMake:CPackPackageGenerators2008-10-30T14:59:37Z<p>Tshead: /* TODO */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged by the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13941CMake:CPackPackageGenerators2008-10-30T14:58:49Z<p>Tshead: /* Bundle Layout */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged by the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13940CMake:CPackPackageGenerators2008-10-30T14:56:21Z<p>Tshead: /* Bundle (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged by the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13939CMake:CPackPackageGenerators2008-10-30T14:55:09Z<p>Tshead: /* Required CMake Variables */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE executable property with the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13938CMake:CPackPackageGenerators2008-10-30T14:52:23Z<p>Tshead: /* TODO */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE executable property with the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13936CMake:CPackPackageGenerators2008-10-29T16:07:49Z<p>Tshead: /* Overview */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE executable property with the bundle-generator! Specifying MACOSX_BUNDLE creates bundle-structures for individual executables at build-time; these structures become redundant when the bundle generator consolidates multiple files into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== TODO ===<br />
<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Support adding background images and extra files to the disk image.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13935CMake:CPackPackageGenerators2008-10-29T16:05:04Z<p>Tshead: /* Bundle (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE executable property with the bundle-generator! MACOSX_BUNDLE creates a bundle-structure for a single executable at build-time, which is redundant when used with the bundle generator. <br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== TODO ===<br />
<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Support adding background images and extra files to the disk image.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13510CMake:CPackPackageGenerators2008-09-16T15:50:48Z<p>Tshead: /* Bundle (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
==Bundle (OSX only)==<br />
<br />
=== Overview ===<br />
<br />
* The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== TODO ===<br />
<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Support adding background images and extra files to the disk image.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13509CMake:CPackPackageGenerators2008-09-16T15:48:45Z<p>Tshead: /* Overview */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
==Bundle (OSX only)==<br />
<br />
=== Overview ===<br />
<br />
* The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13508CMake:CPackPackageGenerators2008-09-16T15:43:16Z<p>Tshead: /* Bundle (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
==Bundle (OSX only)==<br />
<br />
=== Overview ===<br />
<br />
* The Bundle generator creates an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=13507User:Tshead/OSX CPack Bundle Generator2008-09-16T15:41:23Z<p>Tshead: Redirecting to CMake:CPackPackageGenerators#Bundle .28OSX only.29</p>
<hr />
<div>#REDIRECT [[CMake:CPackPackageGenerators#Bundle_.28OSX_only.29]]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=13506CMake:CPackPackageGenerators2008-09-16T15:39:55Z<p>Tshead: /* OSXX11 (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
Currently CPack features the following package generators:<br />
<br />
==TGZ==<br />
<br />
Tar GZip compressed packages.<br />
<br />
==STGZ==<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package.<br />
<br />
==ZIP==<br />
<br />
ZIP compressed packages. Requires zip, WinZip or 7Zip for creating the package. 7Zip support is only available in future version of CMake and can not be used with CMake Version earlier then 2.4.7.<br />
<br />
==TBZ2==<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package.<br />
<br />
==TZ==<br />
<br />
Tar UNIX compress compressed packages.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
==Bundle (OSX only)==<br />
<br />
=== OverView ===<br />
<br />
* The Bundle generator creates an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package: <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: DEBIAN_PACKAGE_SUGGESTS<br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
''Note: CPack RPM generator does not [yet] support [[http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development CPack Component]]. You may monitor the following feature request [[http://public.kitware.com/Bug/view.php?id=7645 #7645]] if you are interested in this.''<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is not different from other CPack generator<br />
it's execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<br />
cd build_dir<br />
make package<br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
==== CPack RPM generators specific variables ====<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package group || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435|Bug7435]])|| -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature inherited from [[CMakeUserUseRPMTools]] which has not been thoroughly tested (yet) || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM Historical Notes ===<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The builtin CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12490User:Tshead/OSX CPack Bundle Generator2008-06-06T16:20:45Z<p>Tshead: /* Behavior */</p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, GTK projects need to start X11 before the "real" application starts, while Qt projects don't require this functionality. In both cases, setting DYLD_LIBRARY_PATH at startup eliminates the need to run install_name_tool on libraries included in the bundle. Some projects require an Info.plist that is more complex than that provided via the current generator. All projects should integrate well with CMake's existing installation functionality.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it bypasses CMake installation. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
You can get a patch for CMake that includes the prototype bundle generator from the CMake bugtracker at http://public.kitware.com/Bug/view.php?id=7170<br />
<br />
== Behavior ==<br />
<br />
* The prototype generator creates an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12489User:Tshead/OSX CPack Bundle Generator2008-06-06T16:16:09Z<p>Tshead: /* Behavior */</p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, GTK projects need to start X11 before the "real" application starts, while Qt projects don't require this functionality. In both cases, setting DYLD_LIBRARY_PATH at startup eliminates the need to run install_name_tool on libraries included in the bundle. Some projects require an Info.plist that is more complex than that provided via the current generator. All projects should integrate well with CMake's existing installation functionality.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it bypasses CMake installation. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
You can get a patch for CMake that includes the prototype bundle generator from the CMake bugtracker at http://public.kitware.com/Bug/view.php?id=7170<br />
<br />
== Behavior ==<br />
<br />
* The prototype generator creates an OSX bundle with the following layout:<br />
<br />
<pre><br />
CPACK_BUNDLE_NAME/<br />
Contents/<br />
MacOS/<br />
CPACK_BUNDLE_NAME (copied from CPACK_BUNDLE_STARTUP_COMMAND)<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from CPACK_BUNDLE_PLIST)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. For most non-trivial applications, it will be a script. The following sample script performs several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image.<br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12488User:Tshead/OSX CPack Bundle Generator2008-06-06T16:10:58Z<p>Tshead: </p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, GTK projects need to start X11 before the "real" application starts, while Qt projects don't require this functionality. In both cases, setting DYLD_LIBRARY_PATH at startup eliminates the need to run install_name_tool on libraries included in the bundle. Some projects require an Info.plist that is more complex than that provided via the current generator. All projects should integrate well with CMake's existing installation functionality.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it bypasses CMake installation. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
You can get a patch for CMake that includes the prototype bundle generator from the CMake bugtracker at http://public.kitware.com/Bug/view.php?id=7170<br />
<br />
== Behavior ==<br />
<br />
* The prototype generator creates an OSX bundle with the following layout:<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
</pre><br />
<br />
* {CPACK_BUNDLE_STARTUP_COMMAND} is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. For most non-trivial applications, it will be a script. The following sample script performs several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12487User:Tshead/OSX CPack Bundle Generator2008-06-06T15:59:48Z<p>Tshead: </p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, GTK projects need to start X11 before the "real" application starts, while Qt projects don't require this functionality. In both cases, setting DYLD_LIBRARY_PATH at startup eliminates the need to run install_name_tool on libraries included in the bundle. Some projects require an Info.plist that is more complex than that provided via the current generator. All projects should integrate well with CMake's existing installation functionality.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it bypasses CMake installation. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
You can get a patch for CMake that includes the prototype bundle generator from the CMake bugtracker at http://public.kitware.com/Bug/view.php?id=7170<br />
<br />
== Behavior ==<br />
<br />
* The prototype generator creates an OSX bundle with the following layout:<br />
<br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(filesystem defined by CMake INSTALL commands)<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
<br />
* {CPACK_BUNDLE_STARTUP_COMMAND} is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. For most non-trivial applications, it will be a script:<br />
** For Qt applications, the script sets DYLD_LIBRARY_PATH and executes one of the binaries installed in the Resources/. <br />
** For GTK applications, the script sets DYLD_LIBRARY_PATH, starts X11, and executes one of the binaries installed in Resources/.<br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12486User:Tshead/OSX CPack Bundle Generator2008-06-06T15:42:09Z<p>Tshead: </p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, projects based on Qt don't need / don't want the functionality to auto-start X11 when the bundle is opened. Other projects need to run a shell-script at startup to setup a special environment. Some projects require an Info.plist that is more complex than that provided via the current generator.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it does not integrate well with CMake INSTALL() functionality. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
You can get a patch for CMake that includes the prototype bundle generator from the CMake bugtracker at http://public.kitware.com/Bug/view.php?id=7170<br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist (hard-coded, generated-elsewhere via CONFIGURE_FILE(), etc).<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead/OSX_CPack_Bundle_Generator&diff=12485User:Tshead/OSX CPack Bundle Generator2008-06-06T15:33:46Z<p>Tshead: New page: == OverView == Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distr...</p>
<hr />
<div>== OverView ==<br />
<br />
Using CMake, I support several cross-platform projects that are deployed on Linux, OSX, and Windows. Some of these projects use Qt, others use GTK. On OSX, I prefer distribution via "bundles" over PackageMaker, but I require more flexibility than the OSXX11 generator provides. For example, projects based on Qt don't need / don't want the functionality to auto-start X11 when the bundle is opened. Other projects need to run a shell-script at startup to setup a special environment. Some projects require an Info.plist that is more complex than that provided via the current generator.<br />
<br />
To do this in the past, I've used "CreateBundle.sh.in" custom shell scripts to do the work of creating bundles, but this is repetitive and error-prone, and it does not integrate well with CMake INSTALL() functionality. What's needed is a more flexible OSX bundle generator for CPack.<br />
<br />
== Prototype ==<br />
<br />
== Required CMake Variables ==<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist (hard-coded, generated-elsewhere via CONFIGURE_FILE(), etc).<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=User:Tshead&diff=12484User:Tshead2008-06-06T15:05:40Z<p>Tshead: New page: Projects: * /OSX CPack Bundle Generator - prototype CPack generator for creating OSX bundles.</p>
<hr />
<div>Projects:<br />
<br />
* [[/OSX CPack Bundle Generator]] - prototype CPack generator for creating OSX bundles.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake/Projects&diff=10879CMake/Projects2007-11-20T16:26:35Z<p>Tshead: /* Applications */</p>
<hr />
<div>= Desktop suites and development platforms =<br />
<br />
* [http://www.kde.org KDE4 ] - the next version of the powerful Open Source desktop, application suite and development platform will be built using CMake, which together with Qt4 will make it possible to run KDE4 not only on Linux/UNIX, but also Mac OS X and Windows.<br />
<br />
=Libraries=<br />
<br />
* [http://www.arl.hpc.mil/ice/ eXtensible Data Model and Format (XDMF)]<br />
<br />
* [http://www-creatis.insa-lyon.fr/Public/Gdcm/ Grass roots DiCoM (GDCM)]<br />
<br />
* [http://vxl.sourceforge.net/ Vision-something-Libraries (VXL)]<br />
<br />
* [http://www.cs.utah.edu/~whitaker/vispack Vispack - C++ library developed for processing volumes images and surfaces ]<br />
<br />
* [http://teem.sourceforge.net Teem - libraries for representing, processing, and visualizing scientific raster data]<br />
<br />
* [http://www.mip.informatik.uni-kiel.de/~wwwadmin/Software/Doc/BIAS/html/intro.html BIAS - The Basic Image AlgorithmS C++ Library ]<br />
<br />
* [http://www.cvgpr.uni-mannheim.de/gosch/software/golib/doc/html GoLib - general c++ library]<br />
<br />
* [http://cmk.navorski.com/index.php?wiki=CmkSql cmkSQL - an abstract SQL Library]<br />
<br />
* [http://www.mcc.uiuc.edu/qmc/AtomicHF/ AtomicHF - Package to solve Hartree-Fock equations for a spherical system using Numerov algorithm] <br />
<br />
* [http://www.xvt.com/ XVT - A software development environment for easily building cross-platform GUI applications in C or C++.] <br />
<br />
* [http://www.vinoisnotouzo.com/hl2sdk-cmake/ The Half-Life 2 SDK in CMake]<br />
<br />
* [http://aften.sourceforge.net/ The aften Open Source A/52 encoder]<br />
<br />
=Toolkits=<br />
<br />
* [http://www.vtk.org Visualization Toolkit VTK]<br />
<br />
* [http://www.itk.org Insight Segmentation and Registration Toolkit ITK]<br />
<br />
* [http://dicom.offis.de/dcmtk.php.en DICOM ToolKit (DCMTK)]<br />
<br />
* [http://www3.ict.csiro.au/ict/content/display/0,,a16254_b16408_d72676,00.html Medical Imaging ToolKit]<br />
<br />
* [http://mbi.dkfz-heidelberg.de/mitk/index.html MITK -Medical Imaging Interaction Toolkit]<br />
<br />
* [http://www.naughter.com/aa.html AA+ - A class framework for Computational Astronomy]<br />
<br />
* [http://fltk.org Fltk - cross-platform C++ GUI toolkit for UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X]<br />
<br />
* [http://fl-inventor.sourceforge.net FlInventor - 3D toolkit]<br />
<br />
* [http://orca-robotics.sourceforge.net/getting.html ORCA - open-source framework for developing component-based robotic systems]<br />
<br />
* [http://www.kwwidgets.org KWWidgets - A free, cross-platform and open-license scientific-visualization GUI Toolkit.]<br />
<br />
* [http://www.igstk.org IGSTK - Image Guided Surgery Toolkit]<br />
<br />
* [http://coolfluidsrv.vki.ac.be/coolfluid COOLFluiD - CFD Environment]<br />
<br />
=Tools=<br />
<br />
* [http://www.gccxml.org GCC-XML - Dumps C++ Interface to XML]<br />
<br />
* [http://ctieware.eng.monash.edu.au/twiki/bin/view/Simulation/IPv6Suite IPv6Suite - open source OMNeT++ model suite for accurate simulation of IPv6 protocols and networks ]<br />
<br />
* [http://www.robots.ox.ac.uk/~pnewman/TheMOOS MOOS - Mission Orientated Operating Suite]<br />
<br />
* [http://www.initng.org/wiki/initng-konf InitNG-Konf - A tool to configure the UNIX init replacement InitNG ]<br />
<br />
=Languages=<br />
<br />
* [http://www.call-with-current-continuation.org Chicken Scheme] - Chicken is a performance oriented Scheme-to-C compiler. It is actively supported on all major C compilers and operating systems. Chicken's CMake build system is extensively commented and is intended to serve as a tutorial for new CMake users. Chicken is a non-trivial, modestly sized project, about 75,000 lines of code. As such, the build system is easier to understand than larger projects, and it has many examples of non-trivial CMake features. For instance, it demonstrates how to use ADD_CUSTOM_COMMAND to drive languages other than C/C++. It also demonstrates the nuances of multi-stage "bootstrapping" problems, i.e. how to generate source files and executables that are needed by the build itself, and how to reuse the same build rules in multiple directories.<br />
<br />
* [http://gpp.niacland.net/telecharger.html.en Goto++ - a goto language]<br />
<br />
* [http://www.compuphase.com/pawn/pawn.htm Pawn - An embedded scripting language formerly called Small]<br />
<br />
=Applications=<br />
* [http://www.aspeed.com ASPEED Software]<br>ASPEED's products include the ACCELLERANT SDK for parallelizing applications for grids or clusters. ASPEED provides APIs for easily improving application performance, with bindings in FORTRAN, C, C++, Java and C#. ACCELLERANT also provides an Application Manager for quickly parallelizing batch jobs from the command line; and Workload Balancer for simple resource management. ACCELLERANT supports Windows and Linux, as well as numerous "grid vendor" products.<br />
::''"ASPEED's SDK supports a wide range of platforms and languages, and CMake fit the bill perfectly for our build and release cycle. It works for Visual Studio IDE development, and it works from the command line under either Windows (nmake) or Linux. It works for FORTRAN as well as C++. It's an enormous time-saver, allowing us to quickly develop applications for multiple platforms. This in turn has allowed us to build, test and release software more frequently, giving us a market advantage."''<br>-Mike Dalessio, Head of Development, ASPEED Software<br />
<br />
* [http://www.paraview.org ParaView Parallel Visualization Application]<br />
<br />
* [http://www.kitware.com/products/volview.html VolView Interactive System for Volume Visualization]<br />
<br />
* [http://www.i-medlab.com CadColon] is a Computer Aided Detection (CAD) system designed to support radiologist's diagnosis of suspect polyps in the colon and rectum, using high and low dose CT.<br />
<br />
''"I started to develop on a project on Linux OS in C++ language on 3 January 2005, and I had never written from scratch any configure.in files, nor used autoconf tools seriously before. So since one of my task was to create the building process for the whole project, I had 2 choices: learn and use autoconf, or search in Internet for an alternative. The one day research ended up in CMake.org, which is an easy but very powerful tool, which allowed me to achieve all I wanted to do (debug/release/profile compilations, compilation based on the developer name, easily maintainable and customizable compilation of many shared/static libraries and applications), and which has a very fast learning curve, exactly what a projet need to achieve its aim in short time."''<br />
<br />
- Luca Cappa<br />
<br />
* [http://davis.wpi.edu/~xmdv Multivariate Data Visualization Tool - XmdvTool]<br />
<br />
* [http://www.evl.uic.edu/cavern/agave/immersaview/index.html ImmersaView]<br />
<br />
* [http://ncmi.bcm.tmc.edu/homes/stevel/EMAN/doc/download.html EMAN - Software for Single Particle Analysis and Electron Micrograph Analysis ] <br />
<br />
* [http://www.slicer.org Slicer - Medical Visualization and Processing Environment for Research]<br />
<br />
* [http://www.5star-shareware.com/Windows/WebDev/HTML/inscite.html InSciTE program editor]<br />
<br />
* [http://boson.eu.org/ Boson - an OpenGL real-time strategy game for UNIX/Linux]<br />
<br />
* [http://www.scribus.net/ Scribus - a powerful Open Source desktop publishing application, developed primarily developed for Linux, now also available for Mac OS X and Windows]<br />
<br />
* [http://www.rosegardenmusic.com/ Rosegarden - a MIDI and audio sequencer and musical notation editor]<br />
<br />
* [http://software.sci.utah.edu/ SCIRun]<br>A visual programming environment for modeling, simulation, and visualization, incorporating thirdparty packages such as Teem, Matlab, and the Insight Toolkit. SCIRun also includes Seg3D, a standalone executable for the segmentation of volumetric image data.<br />
<br />
* [http://www.openwengo.org/ OpenWengo - an open source VoIP telephony application]<br />
<br />
* [http://www.k-3d.org K-3D - free-as-in-freedom 3D graphics for professional artists]<br />
<br />
* [http://www.xtrkcad.org XTrkCAD - a CAD program for designing model railroads]<br />
<br />
* [http://www.aqsis.org Aqsis - a high-quality 3D render engine that implements the RenderMan interface]<br />
<br />
=Controls=<br />
<br />
* [http://www.xs4all.nl/~jorgb/wxFoldPanelBar.html wxFolderPanelBar] and [http://www.xs4all.nl/~jorgb/wxTreeMultiCtrl.html wxTreeMultiCtrl]<br />
<br />
* [http://wxart2d.sourceforge.net/ wxArt2d]<br />
<br />
=Other=<br />
<br />
* [http://plplot.sourceforge.net PLplot] is a mix of a core scientific plotting library written in C, multiple computer language interfaces to that library (some of them generated using [http://www.swig.org/ SWIG]), a set of 20+ test examples written for each computer language interface, multiple plotting device driver plug-ins that are dynamically loaded by our core library, and a complete docbook-based documentation build. This build complexity is handled with ease by CMake on Linux (with good ctest results for the examples written in each computer language that we interface). We are also beginning to get encouraging build results on the Mac OS X and windows platforms.<br />
<br />
* [http://www.opengc.org/index.html OpenGC - The Open Source Glass Cockpit Project]<br />
<br />
* [http://oscar.vision.ee.ethz.ch/gpuseg GPUSEG - Real-Time, GPU-Based Foreground-Background Segmentation]<br />
<br />
* [http://www.tecn.upf.es/openMOIV/ OpenMOIV - is an object-oriented, 3D multi-platform toolkit that helps you develop molecular visualization applications]<br />
<br />
* [http://devolab.cse.msu.edu/software/avida Avida - Digital Life Platform]<br />
<br />
* [http://storm.bmi.ohio-state.edu/documentation.php Storm]<br />
<br />
* [http://www.octave.org Octaviz - Viz for Octave]<br />
<br />
* [http://www.sci.utah.edu/research/annot3d.html Annot3D - 3D annotation system]<br />
<br />
* [http://caddlab.rad.unc.edu/software/MIND MIND - DICOM query/move tool]<br />
<br />
* [http://www.mcc.uiuc.edu/ohmms/ ohmms - object-oriented high-performance solutions for multi-scale materials simulations]<br />
<br />
* [http://www.atracsys.com/_opensource/HornRegistrationDoc/html/ HornRegistration]<br />
<br />
* [http://software.ericsink.com/20040129.html CMake User Review]<br />
<br />
* [http://www.yzis.org/ Yzis - a brand new editor inspired by vim] <br />
<br />
{{CMake/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=CMake/Projects&diff=10844CMake/Projects2007-11-06T16:32:33Z<p>Tshead: </p>
<hr />
<div>= Desktop suites and development platforms =<br />
<br />
* [http://www.kde.org KDE4 ] - the next version of the powerful Open Source desktop, application suite and development platform will be built using CMake, which together with Qt4 will make it possible to run KDE4 not only on Linux/UNIX, but also Mac OS X and Windows.<br />
<br />
=Libraries=<br />
<br />
* [http://www.arl.hpc.mil/ice/ eXtensible Data Model and Format (XDMF)]<br />
<br />
* [http://www-creatis.insa-lyon.fr/Public/Gdcm/ Grass roots DiCoM (GDCM)]<br />
<br />
* [http://vxl.sourceforge.net/ Vision-something-Libraries (VXL)]<br />
<br />
* [http://www.cs.utah.edu/~whitaker/vispack Vispack - C++ library developed for processing volumes images and surfaces ]<br />
<br />
* [http://teem.sourceforge.net Teem - libraries for representing, processing, and visualizing scientific raster data]<br />
<br />
* [http://www.mip.informatik.uni-kiel.de/~wwwadmin/Software/Doc/BIAS/html/intro.html BIAS - The Basic Image AlgorithmS C++ Library ]<br />
<br />
* [http://www.cvgpr.uni-mannheim.de/gosch/software/golib/doc/html GoLib - general c++ library]<br />
<br />
* [http://cmk.navorski.com/index.php?wiki=CmkSql cmkSQL - an abstract SQL Library]<br />
<br />
* [http://www.mcc.uiuc.edu/qmc/AtomicHF/ AtomicHF - Package to solve Hartree-Fock equations for a spherical system using Numerov algorithm] <br />
<br />
* [http://www.xvt.com/ XVT - A software development environment for easily building cross-platform GUI applications in C or C++.] <br />
<br />
* [http://www.vinoisnotouzo.com/hl2sdk-cmake/ The Half-Life 2 SDK in CMake]<br />
<br />
* [http://aften.sourceforge.net/ The aften Open Source A/52 encoder]<br />
<br />
=Toolkits=<br />
<br />
* [http://www.vtk.org Visualization Toolkit VTK]<br />
<br />
* [http://www.itk.org Insight Segmentation and Registration Toolkit ITK]<br />
<br />
* [http://dicom.offis.de/dcmtk.php.en DICOM ToolKit (DCMTK)]<br />
<br />
* [http://www3.ict.csiro.au/ict/content/display/0,,a16254_b16408_d72676,00.html Medical Imaging ToolKit]<br />
<br />
* [http://mbi.dkfz-heidelberg.de/mitk/index.html MITK -Medical Imaging Interaction Toolkit]<br />
<br />
* [http://www.naughter.com/aa.html AA+ - A class framework for Computational Astronomy]<br />
<br />
* [http://fltk.org Fltk - cross-platform C++ GUI toolkit for UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X]<br />
<br />
* [http://fl-inventor.sourceforge.net FlInventor - 3D toolkit]<br />
<br />
* [http://orca-robotics.sourceforge.net/getting.html ORCA - open-source framework for developing component-based robotic systems]<br />
<br />
* [http://www.kwwidgets.org KWWidgets - A free, cross-platform and open-license scientific-visualization GUI Toolkit.]<br />
<br />
* [http://www.igstk.org IGSTK - Image Guided Surgery Toolkit]<br />
<br />
=Tools=<br />
<br />
* [http://www.gccxml.org GCC-XML - Dumps C++ Interface to XML]<br />
<br />
* [http://ctieware.eng.monash.edu.au/twiki/bin/view/Simulation/IPv6Suite IPv6Suite - open source OMNeT++ model suite for accurate simulation of IPv6 protocols and networks ]<br />
<br />
* [http://www.robots.ox.ac.uk/~pnewman/TheMOOS MOOS - Mission Orientated Operating Suite]<br />
<br />
* [http://www.initng.org/wiki/initng-konf InitNG-Konf - A tool to configure the UNIX init replacement InitNG ]<br />
<br />
=Languages=<br />
<br />
* [http://www.call-with-current-continuation.org Chicken Scheme] - Chicken is a performance oriented Scheme-to-C compiler. It is actively supported on all major C compilers and operating systems. Chicken's CMake build system is extensively commented and is intended to serve as a tutorial for new CMake users. Chicken is a non-trivial, modestly sized project, about 75,000 lines of code. As such, the build system is easier to understand than larger projects, and it has many examples of non-trivial CMake features. For instance, it demonstrates how to use ADD_CUSTOM_COMMAND to drive languages other than C/C++. It also demonstrates the nuances of multi-stage "bootstrapping" problems, i.e. how to generate source files and executables that are needed by the build itself, and how to reuse the same build rules in multiple directories.<br />
<br />
* [http://gpp.niacland.net/telecharger.html.en Goto++ - a goto language]<br />
<br />
* [http://www.compuphase.com/pawn/pawn.htm Pawn - An embedded scripting language formerly called Small]<br />
<br />
=Applications=<br />
* [http://www.aspeed.com ASPEED Software]<br>ASPEED's products include the ACCELLERANT SDK for parallelizing applications for grids or clusters. ASPEED provides APIs for easily improving application performance, with bindings in FORTRAN, C, C++, Java and C#. ACCELLERANT also provides an Application Manager for quickly parallelizing batch jobs from the command line; and Workload Balancer for simple resource management. ACCELLERANT supports Windows and Linux, as well as numerous "grid vendor" products.<br />
::''"ASPEED's SDK supports a wide range of platforms and languages, and CMake fit the bill perfectly for our build and release cycle. It works for Visual Studio IDE development, and it works from the command line under either Windows (nmake) or Linux. It works for FORTRAN as well as C++. It's an enormous time-saver, allowing us to quickly develop applications for multiple platforms. This in turn has allowed us to build, test and release software more frequently, giving us a market advantage."''<br>-Mike Dalessio, Head of Development, ASPEED Software<br />
<br />
* [http://www.paraview.org ParaView Parallel Visualization Application]<br />
<br />
* [http://www.kitware.com/products/volview.html VolView Interactive System for Volume Visualization]<br />
<br />
* [http://www.i-medlab.com CadColon] is a Computer Aided Detection (CAD) system designed to support radiologist's diagnosis of suspect polyps in the colon and rectum, using high and low dose CT.<br />
<br />
''"I started to develop on a project on Linux OS in C++ language on 3 January 2005, and I had never written from scratch any configure.in files, nor used autoconf tools seriously before. So since one of my task was to create the building process for the whole project, I had 2 choices: learn and use autoconf, or search in Internet for an alternative. The one day research ended up in CMake.org, which is an easy but very powerful tool, which allowed me to achieve all I wanted to do (debug/release/profile compilations, compilation based on the developer name, easily maintainable and customizable compilation of many shared/static libraries and applications), and which has a very fast learning curve, exactly what a projet need to achieve its aim in short time."''<br />
<br />
- Luca Cappa<br />
<br />
* [http://davis.wpi.edu/~xmdv Multivariate Data Visualization Tool - XmdvTool]<br />
<br />
* [http://www.evl.uic.edu/cavern/agave/immersaview/index.html ImmersaView]<br />
<br />
* [http://ncmi.bcm.tmc.edu/homes/stevel/EMAN/doc/download.html EMAN - Software for Single Particle Analysis and Electron Micrograph Analysis ] <br />
<br />
* [http://www.slicer.org Slicer - Medical Visualization and Processing Environment for Research]<br />
<br />
* [http://www.5star-shareware.com/Windows/WebDev/HTML/inscite.html InSciTE program editor]<br />
<br />
* [http://boson.eu.org/ Boson - an OpenGL real-time strategy game for UNIX/Linux]<br />
<br />
* [http://www.scribus.net/ Scribus - a powerful Open Source desktop publishing application, developed primarily developed for Linux, now also available for Mac OS X and Windows]<br />
<br />
* [http://www.rosegardenmusic.com/ Rosegarden - a MIDI and audio sequencer and musical notation editor]<br />
<br />
* [http://software.sci.utah.edu/ SCIRun]<br>A visual programming environment for modeling, simulation, and visualization, incorporating thirdparty packages such as Teem, Matlab, and the Insight Toolkit. SCIRun also includes Seg3D, a standalone executable for the segmentation of volumetric image data.<br />
<br />
* [http://www.openwengo.org/ OpenWengo - an open source VoIP telephony application]<br />
<br />
* [http://www.k-3d.org K-3D - free-as-in-freedom 3D graphics for professional artists]<br />
<br />
* [http://www.xtrkcad.org XTrkCAD - a CAD program for designing model railroads]<br />
<br />
=Controls=<br />
<br />
* [http://www.xs4all.nl/~jorgb/wxFoldPanelBar.html wxFolderPanelBar] and [http://www.xs4all.nl/~jorgb/wxTreeMultiCtrl.html wxTreeMultiCtrl]<br />
<br />
* [http://wxart2d.sourceforge.net/ wxArt2d]<br />
<br />
=Other=<br />
<br />
* [http://plplot.sourceforge.net PLplot] is a mix of a core scientific plotting library written in C, multiple computer language interfaces to that library (some of them generated using [http://www.swig.org/ SWIG]), a set of 20+ test examples written for each computer language interface, multiple plotting device driver plug-ins that are dynamically loaded by our core library, and a complete docbook-based documentation build. This build complexity is handled with ease by CMake on Linux (with good ctest results for the examples written in each computer language that we interface). We are also beginning to get encouraging build results on the Mac OS X and windows platforms.<br />
<br />
* [http://www.opengc.org/index.html OpenGC - The Open Source Glass Cockpit Project]<br />
<br />
* [http://oscar.vision.ee.ethz.ch/gpuseg GPUSEG - Real-Time, GPU-Based Foreground-Background Segmentation]<br />
<br />
* [http://www.tecn.upf.es/openMOIV/ OpenMOIV - is an object-oriented, 3D multi-platform toolkit that helps you develop molecular visualization applications]<br />
<br />
* [http://devolab.cse.msu.edu/software/avida Avida - Digital Life Platform]<br />
<br />
* [http://storm.bmi.ohio-state.edu/documentation.php Storm]<br />
<br />
* [http://www.octave.org Octaviz - Viz for Octave]<br />
<br />
* [http://www.sci.utah.edu/research/annot3d.html Annot3D - 3D annotation system]<br />
<br />
* [http://caddlab.rad.unc.edu/software/MIND MIND - DICOM query/move tool]<br />
<br />
* [http://www.mcc.uiuc.edu/ohmms/ ohmms - object-oriented high-performance solutions for multi-scale materials simulations]<br />
<br />
* [http://www.atracsys.com/_opensource/HornRegistrationDoc/html/ HornRegistration]<br />
<br />
* [http://software.ericsink.com/20040129.html CMake User Review]<br />
<br />
* [http://www.yzis.org/ Yzis - a brand new editor inspired by vim] <br />
<br />
{{CMake/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III&diff=8002ParaView III2006-12-11T19:03:48Z<p>Tshead: </p>
<hr />
<div>The next major version of ParaView (III) includes many significant improvements, including:<br />
<br />
* New Qt interface<br />
* Much better support for Python scripting<br />
* Emphasis on quantitative analysis<br />
<br />
ParaView III is under development by a team including Kitware, Sandia National Labs and Elemental Technologies. Until ParaView III is ready for release, we will release a snapshot every month. These snapshots can be obtained from [[ParaView III snapshots]]. You may also view automated test results using the [http://paraview.org/ParaView3/Testing ParaView III Dashboard].<br />
<br />
'''''Win32 Users:''''' If you wish to build ParaView III from source using the GPL'd version of Qt and Visual Studio, see [[Obtaining GPL'ed Qt for Windows]].<br />
<br />
'''''Linux/Unix/OS X Users:''''' If you are building from source, you might want to include the FFMPEG encoder. For this, you need to build the encoder from source. Download it here [http://vtk.org/get-software.php#addons here]. Build instructions are included with the package. <br />
<br />
If you have questions about licensing, see [[ParaView III and Qt licensing]].<br />
<br />
== ParaView III Features ==<br />
<br />
Here are some excerpts from the ParaView 3 development wiki. These should give some insight to the new features that are/will be available in ParaView 3.<br />
<br />
* [[Selection Implementation in VTK and ParaView III]]<br />
* [[Disconnecting from server while still saving an animation]]<br />
* [[Server Resources]]<br />
* [[Server Configuration]]<br />
* [[Starting the server]]<br />
* [[Multiple views]]<br />
* [[ParaView:pvpython|Python scripting]]<br />
* [[Testing design]]<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=8001Obtaining GPL'ed Qt for Windows2006-12-11T18:56:48Z<p>Tshead: /* Installation */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/paraview-qt-win-opensource-src-4.2.2.zip paraview-qt-win-opensource-src-4.2.2.zip], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the paraview-qt-win-opensource-src-4.2.2.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraview-qt-win-opensource-src-4.2.2 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraview-qt-win-opensource-src-4.2.2> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraview-qt-win-opensource-src-4.2.2\bin.<br />
* Use CMake to build ParaView normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default, which will lead to compile errors when you compile the sources later-on.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default, which will lead to compile errors when you compile the sources later-on.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p1 -i qtwin_patch/msvc_bcc32_42.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=8000Obtaining GPL'ed Qt for Windows2006-12-11T16:25:33Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default, which will lead to compile errors when you compile the sources later-on.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default, which will lead to compile errors when you compile the sources later-on.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p1 -i qtwin_patch/msvc_bcc32_42.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7999Obtaining GPL'ed Qt for Windows2006-12-11T16:23:49Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default!<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place. '''''Note:''''' ensure that your archive utility restores permissions and ownership for the zip file contents. Some tools (such as cygwin ''unzip'') don't do this by default!<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p1 -i qtwin_patch/msvc_bcc32_42.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7984Obtaining GPL'ed Qt for Windows2006-12-08T21:33:51Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p1 -i qtwin_patch/msvc_bcc32_42.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7983Obtaining GPL'ed Qt for Windows2006-12-08T21:32:15Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_42.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7982Obtaining GPL'ed Qt for Windows2006-12-08T21:18:15Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2.2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_422.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7981Obtaining GPL'ed Qt for Windows2006-12-08T21:16:16Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources.<br />
* Download [http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip acs-4.2.2-patch1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs-4.2.2-patch1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs-4.2.2-patch1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2l2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_422.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7980Obtaining GPL'ed Qt for Windows2006-12-08T21:12:54Z<p>Tshead: /* Advanced Users */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.2.2.zip qt-win-opensource-src-4.2.2.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.2.2.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.2.2 directory containing the full Qt sources.<br />
* Download [http://prdownloads.sourceforge.net/qtwin/acs4qt422p1.zip?download acs4qt422p1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs4qt422p1.zip to the c:\qt\qt-win-opensource-src-4.2.2 directory.<br />
* Expand acs4qt422p1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.2l2<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_422.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7979Obtaining GPL'ed Qt for Windows2006-12-08T20:47:39Z<p>Tshead: /* Overview */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.2 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.1.4.zip qt-win-opensource-src-4.1.4.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.1.4.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.1.4 directory containing the full Qt sources.<br />
* Download [http://prdownloads.sourceforge.net/qtwin/acs4qt414p1.zip?download acs4qt414p1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs4qt414p1.zip to the c:\qt\qt-win-opensource-src-4.1.4 directory.<br />
* Expand acs4qt414p1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.1.4<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_414.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7978Obtaining GPL'ed Qt for Windows2006-12-08T20:47:08Z<p>Tshead: /* Older Versions */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.1 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.1.4.zip qt-win-opensource-src-4.1.4.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.1.4.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.1.4 directory containing the full Qt sources.<br />
* Download [http://prdownloads.sourceforge.net/qtwin/acs4qt414p1.zip?download acs4qt414p1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs4qt414p1.zip to the c:\qt\qt-win-opensource-src-4.1.4 directory.<br />
* Expand acs4qt414p1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.1.4<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_414.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Obtaining_GPL%27ed_Qt_for_Windows&diff=7977Obtaining GPL'ed Qt for Windows2006-12-08T20:46:01Z<p>Tshead: /* Older Versions */</p>
<hr />
<div>== Overview ==<br />
<br />
On Win32 operating systems, [http://www.trolltech.com Trolltech] has adopted a policy of crippling their GPL'd "open source edition" of Qt 4.1 so that it can only be built using the [http://www.mingw.org MinGW] environment, which is based upon the gcc compiler ported to Win32. Developers who wish to use Qt with Microsoft compilers would normally be encouraged to purchase the commercial edition of Qt, see the Trolltech [http://www.trolltech.com/developer/knowledgebase/389 FAQ entry] on this subject. Because Microsoft compilers are preferred for ParaQ builds on Win32, we are providing a patched version of the Qt GPL sources that can be built with Microsoft tools.<br />
<br />
== Installation ==<br />
<br />
* Download [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4.1.4.zip this file], saving it to a convenient location (c:\qt is strongly recommended).<br />
* Expand the Paraview-qt-win-opensource-src-4.1.4.zip file.<br />
* Start a DOS shell, and cd to the c:\qt\paraq-qt-win-opensource-src-4.1.4 directory.<br />
* Run the Qt configure '''script''' ('''not''' configure.exe):<br />
<br />
c:\qt\paraq-qt-win-opensource-src-4.1.4> qconfigure.bat<br />
<br />
* From this point forward, compilation and deployment of the Qt libraries should proceed normally. Begin compilation using the in-console instructions provided by the configuration process.<br />
* Configure your PATH to point to c:\qt\paraq-qt-win-opensource-src-4.1.4\bin.<br />
* Use CMake to build ParaQ normally.<br />
<br />
== Advanced Users ==<br />
<br />
For the curious, here is the procedure used to patch the Qt GPL sources:<br />
<br />
The [http://sourceforge.net/projects/qtwin/ QtWin Project] provides a set of patches that allow the Qt GPL libraries to be built with Microsoft compilers. You will need [http://sourceware.org/cygwin Cygwin] installed on your machine to provide the "patch" command.<br />
<br />
* If you don't already have Cygwin installed (why not?), run [http://sourceware.org/cygwin/setup.exe Cygwin Setup] to download and install Cygwin.<br />
* Download [http://www.trolltech.com/download.html?target=ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.1.4.zip qt-win-opensource-src-4.1.4.zip] from Trolltech.<br />
* Expand qt-win-opensource-src-4.1.4.zip in a convenient location such as c:\qt. This will create a c:\qt\qt-win-opensource-src-4.1.4 directory containing the full Qt sources.<br />
* Download [http://prdownloads.sourceforge.net/qtwin/acs4qt414p1.zip?download acs4qt414p1.zip] from the [http://sourceforge.net/projects/qtwin QtWin] project.<br />
* Move the downloaded file acs4qt414p1.zip to the c:\qt\qt-win-opensource-src-4.1.4 directory.<br />
* Expand acs4qt414p1.zip in place.<br />
* Start a Cygwin shell, and cd to your new Qt source directory:<br />
<br />
$ cd /cygdrive/c/qt/qt-win-opensource-src-4.1.4<br />
<br />
* Patch the Qt sources:<br />
<br />
$ patch -p0 -i msvc_bcc32_414.patch<br />
<br />
* Voila!<br />
<br />
== Older Versions ==<br />
<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-0.zip]<br />
* [http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-4.zip http://paraview.org/files/v2.9/ParaView-qt-win-opensource-src-4-1-4.zip]</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III&diff=7336ParaView III2006-10-10T21:47:13Z<p>Tshead: /* ParaView III Features */</p>
<hr />
<div>The next major version of ParaView (III) will include important improvements including:<br />
<br />
* New Qt interface<br />
* Much better support for Python scripting<br />
* Emphasis on quantitative analysis<br />
<br />
ParaView III is currently being developed by a team including Kitware, Sandia National Labs and Elemental Technologies. Until ParaView III is ready to be release, we will release a snapshot every months. These snapshot can be obtained from [[ParaView III snapshots|here]]. You can access ParaView III dashboard [http://paraview.org/ParaView3/Testing here].<br />
<br />
If you decide to build ParaView from source, you will have to download and compile the GPL'ed version of Qt. The files are [http://www.trolltech.com/products/qt/downloads here]. If you are a Windows developer and you want to develop using Visual Studio, you need obtain the GPL'ed version of Qt. This is not provided by Trolltech. Instructions for downloading it are [[Obtaining GPL'ed Qt for Windows|here]].<br />
<br />
Also, if you are building from source on Linux/Unix/Mac OS X, you might want to include the FFMPEG encoder. For this, you need to build the encoder from source. Download it here [http://vtk.org/get-software.php#addons here]. Build instructions are included with the package. <br />
<br />
If you have questions about licensing, go [[ParaView III and Qt licensing|here]].<br />
<br />
== ParaView III Features ==<br />
<br />
Here are some excerpts from the ParaView 3 development wiki. These should give some insight to the new features that are/will be available in ParaView 3.<br />
<br />
* [[Selection Implementation in VTK and ParaView III]]<br />
* [[Disconnecting from server while still saving an animation]]<br />
* [[Server Resources]]<br />
* [[Server Configuration]]<br />
* [[Starting the server]]<br />
* [[Multiple views]]<br />
* [[ParaView:pvpython|Python scripting]]<br />
* [[Testing design]]<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Server_Configuration&diff=7238Server Configuration2006-10-05T20:10:37Z<p>Tshead: /* Runtime Environment */</p>
<hr />
<div>== Overview ==<br />
<br />
To simplify the user experience, many sites may opt to provide predefined ParaView server configurations for their users, which can be done with an external XML file - see [[Starting the server]]. Although server configuration is new to ParaView, similar functionality already exists in ParaView Enterprise. This page defines an XML schema for storing server configurations that is based on the existing functionality.<br />
<br />
== Example ==<br />
<br />
Following is an example of the proposed server configuration XML:<br />
<br />
<pre><br />
<Servers><br />
<br />
<Server name="localhost (forward)" resource="cs://localhost" owner="site"><br />
<CommandStartup><br />
<Command exec="cmd" timeout="120" delay="3"><br />
<Arguments><br />
<Argument value="/c" /><br />
<Argument value="start" /><br />
<Argument value="/b" /><br />
<Argument value="pvserver" /><br />
<Argument value="--server-port=$PV_SERVER_PORT$" /><br />
<Argument value="--use-offscreen-rendering" /><br />
</Arguments><br />
</Command><br />
</CommandStartup><br />
</Server><br />
<br />
<Server name="localhost (forward - with port selection)" resource="cs://localhost" owner="site"><br />
<CommandStartup><br />
<Options><br />
<Option name="PV_SERVER_PORT" label="Port"><br />
<Range type="int" min="1" max="65535" step="1" default="11111" /><br />
</Option><br />
</Options><br />
<Command exec="cmd" timeout="120" delay="3"><br />
<Arguments><br />
<Argument value="/c" /><br />
<Argument value="start" /><br />
<Argument value="/b" /><br />
<Argument value="pvserver" /><br />
<Argument value="--server-port=$PV_SERVER_PORT$" /><br />
<Argument value="--use-offscreen-rendering" /><br />
</Arguments><br />
</Command><br />
</CommandStartup><br />
</Server><br />
<br />
<Server name="localhost (forward - with connect ID)" resource="cs://localhost" owner="site"><br />
<CommandStartup><br />
<Options><br />
<Option name="PV_CONNECT_ID" label="Connect ID"><br />
<Range type="int" min="1" max="65535" step="1" default="random" /><br />
</Option><br />
</Options><br />
<Command exec="cmd" timeout="120" delay="3"><br />
<Arguments><br />
<Argument value="/c" /><br />
<Argument value="start" /><br />
<Argument value="/b" /><br />
<Argument value="pvserver" /><br />
<Argument value="--server-port=$PV_SERVER_PORT$" /><br />
<Argument value="--use-offscreen-rendering" /><br />
<Argument value="--connect-id=$PV_CONNECT_ID$" /><br />
</Arguments><br />
</Command><br />
</CommandStartup><br />
</Server><br />
<br />
<Server name="localhost (reverse)" resource="csrc://localhost" owner="user"><br />
<ManualStartup/><br />
</Server><br />
<br />
<Server name="localhost (reverse - with port selection)" resource="csrc://localhost" owner="user"><br />
<ManualStartup><br />
<Options><br />
<Option name="PV_SERVER_PORT" label="Port"><br />
<Range type="int" min="1" max="65535" step="1" default="11111" /><br />
</Option><br />
</Options><br />
</ManualStartup><br />
</Server><br />
<br />
<Server name="jupiter" resource="cs://jupiter" owner="site" ><br />
<CommandStartup><br />
<Options><br />
<Option name="NODES" label="Number of Nodes"><br />
<Range type="int" min="1" max="1024" step="1" default="1" /><br />
</Option><br />
<Option name="MINUTES" label="Number of Minutes"><br />
<Range type="int" min="1" max="3600" step="15" default="60" /><br />
</Option><br />
<Option name="COMPURATE" label="Comp-U-Rate"><br />
<Range type="double" min="1" max="99999999" step="0.1" precision="1" default="1.5" /><br />
</Option><br />
<Option name="PROJECTTASK" label="Project/Task"><br />
<String default="123/4.5" /><br />
</Option><br />
<Option name="FLAVORENDER" label="Enable Flav-O-Render"><br />
<Boolean true="--flav-o-render" false="" default="true"/><br />
</Option><br />
<Option name="FLAVOR" label="Flavor"><br />
<Enumeration default="cherry"><br />
<Entry value="cherry" label="Cherry" /><br />
<Entry value="lime" label="Lime" /><br />
<Entry value="rutabaga" label="Rutabaga" /><br />
</Enumeration><br />
</Option><br />
<Option name="NUTTINESS" label="Nuttiness" readonly="true" ><br />
<Range type="int" min="1" max="65535" step="1" default="random" /><br />
</Option><br />
</Options><br />
<Command exec="cmd" timeout="120" delay="5"><br />
<Arguments><br />
<Argument value="/c" /><br />
<Argument value="start" /><br />
<Argument value="/b" /><br />
<Argument value="mystartup" /><br />
<Argument value="--server-port=$PV_SERVER_PORT$" /><br />
<Argument value="--nodes=$NODES$" /><br />
<Argument value="--minutes=$MINUTES$" /><br />
<Argument value="--compurate=$COMPURATE$" /><br />
<Argument value="--project-task=$PROJECTTASK$" /><br />
<Argument value="$FLAVORENDER$" /><br />
<Argument value="--flavor=$FLAVOR$" /><br />
<Argument value="--nuttiness=$NUTTINESS$" /><br />
</Arguments><br />
</Command><br />
</CommandStartup><br />
</Server><br />
<br />
</Servers><br />
</pre><br />
<br />
== Notes ==<br />
<br />
* The <Servers> tag is the root element of the document, which contains zero-to-many <Server> tags.<br />
* Each <Server> tag represents a configured server:<br />
** The "name" attribute uniquely identifies the server configuration, and is displayed in the user interface.<br />
** The "resource" attribute specifies the type of server connection, server host(s) and optional port(s) for making a connection. See [[Server Resources]].<br />
** The "owner" attribute specifies where the configuration originated, current valid values are "builtin" (the configuration was hard-coded into the application), "site" (the configuration was setup by site administrators), or "user" (the configuration was setup by the user). The client uses this information to set policy, e.g: "builtin" and "site" configurations are read-only, only "user" configurations are stored in per-user preferences, etc.<br />
* The <CommandStartup> tag is used to run an external command to start a server.<br />
** An optional <Options> tag can be used to prompt the user for options required at startup.<br />
*** Each <Option> tag represents an option that the user will be prompted to modify before startup.<br />
**** The "name" attribute defines the name of the option, which will become its variable name when used as an environment variable, and for purposes of string-substitution in <Argument> tags.<br />
**** The "label" attribute defines a human-readable label for the option, which will be used in the user interface.<br />
**** The optional "readonly" attribute can be used to designate options which are user-visible, but cannot be modified.<br />
**** A <Range> tag designates a numeric option that is only valid over a range of values.<br />
***** The "type" attribute controls the type of number controlled. Valid values are "int" for integers and "double" for floating-point numbers, respectively.<br />
***** The "min" and "max" attributes specify the minimum and maximum allowable values for the option (inclusive).<br />
***** The "step" attribute specifies the preferred amount to increment / decrement values in the user interface.<br />
***** The "default" attribute specifies the initial value of the option.<br />
****** As a special-case for integer ranges, a default value of "random" will generate a random number as the default each time the user is prompted for a value. This is particularly useful with PV_CONNECT_ID.<br />
**** A <String> tag designates an option that accepts freeform text as its value.<br />
***** The "default" attribute specifies the initial value of the option.<br />
**** A <Boolean> tag designates an option that is either on/off or true/false.<br />
***** The "true" attribute specifies what the option value will be if enabled by the user.<br />
***** The "false" attribute specifies what the option value will be if disabled by the user.<br />
***** The "default" attribute specifies the initial value of the option, either "true" or "false".<br />
**** An <Enumeration> tag designates an option that can be one of a finite set of values.<br />
***** The "default" attribute specifies the initial value of the option, which must be one of its enumerated values.<br />
***** Each <Entry> tag describes one allowed value.<br />
****** The "name" tag specifies the value for that choice.<br />
****** The "label" tag provides human-readable text that will be displayed in the user interface for that choice.<br />
** A <Command> tag is used to specify the external command and its startup arguments.<br />
*** The "exec" attribute specifies the filename of the command to be run. The system PATH will be used to search for the command, unless an absolute path is specified.<br />
*** The "timeout" attribute specifies the maximum amount of time (in seconds) that the client will wait for the server to start ('''''currently not implemented''''').<br />
*** The "delay" attribute specifies a delay (in seconds) between the time the startup command completes and the time that the client attempts a connection to the server.<br />
*** <Argument> tags are command-line arguments that will be passed to the startup command.<br />
**** String substitution is performed on each argument, replacing each $STRING$ with the value of a predefined or user-defined variable.<br />
**** Arguments whose value is an empty string are not passed to the startup command.<br />
* The <ManualStartup> tag indicates that the user will manually start the given server prior to connecting.<br />
** An optional <Options> tag can be used to prompt the user for options required at startup. Note that PV_SERVER_PORT, PV_DATA_SERVER_PORT, PV_RENDER_SREVER_PORT, and PV_CONNECT_ID are the only variables that make sense in this context.<br />
* Other startup type tags may be added in the future to support e.g: builtin SSH client functionality.<br />
<br />
=== Runtime Environment ===<br />
<br />
When a startup command is run, its environment will include all of the user-defined variables specified in <Option> tags, plus the following predefined variables:<br />
<br />
* PV_CONNECTION_URI<br />
* PV_CONNECTION_SCHEME<br />
* PV_CLIENT_HOST<br />
* PV_SERVER_HOST<br />
* PV_SERVER_PORT<br />
* PV_DATA_SERVER_HOST<br />
* PV_DATA_SERVER_PORT<br />
* PV_RENDER_SERVER_HOST<br />
* PV_RENDER_SERVER_PORT<br />
* PV_USERNAME ('''''currently not implemented''''')<br />
* PV_CONNECT_ID<br />
<br />
If an <Option> tag defines a variable with the same name as a predefined variable, the <Option> tag value takes precedence. This can be used to override defaults that are normally hidden from the user. As an example, if a site wanted users to be able to override default port numbers, the server configuration might specify an <Option> of PV_SERVER_PORT.</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Starting_the_server&diff=7237Starting the server2006-10-04T22:06:54Z<p>Tshead: /* GNU/Linux */</p>
<hr />
<div>== Overview ==<br />
<br />
Past versions of ParaView have required users to start client and server manually, specifying connection protocols and parameters at the command-line. ParaView3 improves the user experience by allowing users to start the client and make/break server connections using the client's graphical user interface.<br />
<br />
For this functionality to work, ParaView must be properly configured to start remote servers. Startup procedures are expected to vary from site-to-site, due to differences in network topology, firewalls, address translation, logging requirements, etc. To accomodate this, a flexible mechanism allows users to run arbitrary commands on a per-server and/or per-connection-scheme basis at server startup.<br />
<br />
<br />
== Managing Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
The collection of configured servers can be accessed through the "Server Browser" dialog, which presents a listing of servers that are already configured. The Server Browser dialog is displayed whenever you:<br />
<br />
* Select the ''File > Connect'' menu item or corresponding toolbar button.<br />
* Choose the ''File > Open'' menu item or toolbar button and there is no server currently connected.<br />
* Select an item from the ''File > Recent Files'' menu for which there is ''more than one'' possible server configuration that could be used for the item selected.<br />
<br />
The Server Browser dialog contains standard controls for editing, deleting, and adding new server configurations. Additions and changes to configured servers are stored in per-user preferences. Server configuration data can also be saved and loaded to the local filesystem in XML format using the provided controls.<br />
<br />
If a server configuration file named ''default_servers.pvsc'' is located in the same directory as the ParaView binary executable, it will be loaded at startup time. Per-user preferences are loaded after ''default_servers.pvsc'', so they can override its contents. Note that additions, deletions, and changes to servers never alter the contents of ''default_servers.pvsc''. See [[Server Configuration]] for details on the XML schema used by ''default_servers.pvsc''.<br />
<br />
</td><br />
<td><br />
[[Image:Server browser.png|thumb|right|200px|'''Figure 1: "Server Browser" dialog displaying the list of configured servers.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Configuring New Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
If the user chooses ''Add Server'' in the "Manage Servers" dialog or chooses an item from the ''File > Recent Files'' menu for which a server configuration doesn't exist, the "Configure New Server" dialog opens. The user is prompted to select a name for the server configuration, the type of server connection to configure (see [[Server Resources]]), and the host or hosts that will be used for the new configuration.<br />
</td><br />
<td><br />
[[Image:Configure_new_server.png|thumb|right|300px|'''Figure 2: "Configure New Server" dialog''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Editing Server Configuration ==<br />
<br />
After creating a new server or choosing ''Edit Server'' from the Server Browser dialog, the "Configure Server" dialog opens.<br />
<br />
Note that the Configure Server dialog will display server configurations loaded from ''default_servers.pvsc'' in a "read-only" state.<br />
<br />
=== Command Startup ===<br />
<br />
<table><br />
<tr><br />
<td><br />
For new server configurations, the dialog defaults to a ''Command'' startup configuration. In this case ParaView will run an external command to start the server. The external command will be run using exec() (Posix systems) or CreateProcess() (Win32), so shell-specific functionality such as redirection or "&" cannot be used (unless you invoke a specific shell directly).<br />
<br />
The external command cannot block while the server is running, it should start the server in the background and return.<br />
<br />
Users may configure a delay between the time the startup command returns and the time that the client attempts connection.<br />
<br />
A set of predefined and user-defined environment variables are used to communicate connection parameters to the command, see [[Server Configuration]] for details on variables and site-specific configuration.<br />
<br />
</td><br />
<td><br />
[[Image:Configure_command_startup.png|thumb|right|300px|'''Figure 3: "Configure Server" dialog, specifying "Command" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
=== Manual Startup ===<br />
<br />
<table width="100%"><br />
<tr><br />
<td><br />
Users who prefer to start servers manually can specify as such in the "Configure Server" dialog. In this case, the user must ensure that the server(s) are running before attempting to connect with the ParaView client.<br />
</td><br />
<td><br />
[[Image:Configure_manual_startup.png|thumb|right|300px|'''Figure 4: "Configure Server" dialog, specifying "Manual" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Sample Startup Commands ==<br />
<br />
=== Win32 ===<br />
<br />
To start a server on the local host:<br />
<br />
cmd /c start /b pvserver --server-port=%PV_SERVER_PORT% --use-offscreen-rendering<br />
<br />
''cmd /c start /b'' is used to start pvserver in the background on Win32.<br />
<br />
=== GNU/Linux ===<br />
<br />
To start a server on the local host:<br />
<br />
python -c "import os; os.system('pvserver --use-offscreen-rendering &')" <br />
<br />
... in this case, os.system() allows us to use the shell "&" to start pvserver in the background. Other useful tools on Posix operating systems include ''nohup'' and ''daemonize''.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Starting_the_server&diff=7236Starting the server2006-10-04T22:06:20Z<p>Tshead: /* Win32 */</p>
<hr />
<div>== Overview ==<br />
<br />
Past versions of ParaView have required users to start client and server manually, specifying connection protocols and parameters at the command-line. ParaView3 improves the user experience by allowing users to start the client and make/break server connections using the client's graphical user interface.<br />
<br />
For this functionality to work, ParaView must be properly configured to start remote servers. Startup procedures are expected to vary from site-to-site, due to differences in network topology, firewalls, address translation, logging requirements, etc. To accomodate this, a flexible mechanism allows users to run arbitrary commands on a per-server and/or per-connection-scheme basis at server startup.<br />
<br />
<br />
== Managing Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
The collection of configured servers can be accessed through the "Server Browser" dialog, which presents a listing of servers that are already configured. The Server Browser dialog is displayed whenever you:<br />
<br />
* Select the ''File > Connect'' menu item or corresponding toolbar button.<br />
* Choose the ''File > Open'' menu item or toolbar button and there is no server currently connected.<br />
* Select an item from the ''File > Recent Files'' menu for which there is ''more than one'' possible server configuration that could be used for the item selected.<br />
<br />
The Server Browser dialog contains standard controls for editing, deleting, and adding new server configurations. Additions and changes to configured servers are stored in per-user preferences. Server configuration data can also be saved and loaded to the local filesystem in XML format using the provided controls.<br />
<br />
If a server configuration file named ''default_servers.pvsc'' is located in the same directory as the ParaView binary executable, it will be loaded at startup time. Per-user preferences are loaded after ''default_servers.pvsc'', so they can override its contents. Note that additions, deletions, and changes to servers never alter the contents of ''default_servers.pvsc''. See [[Server Configuration]] for details on the XML schema used by ''default_servers.pvsc''.<br />
<br />
</td><br />
<td><br />
[[Image:Server browser.png|thumb|right|200px|'''Figure 1: "Server Browser" dialog displaying the list of configured servers.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Configuring New Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
If the user chooses ''Add Server'' in the "Manage Servers" dialog or chooses an item from the ''File > Recent Files'' menu for which a server configuration doesn't exist, the "Configure New Server" dialog opens. The user is prompted to select a name for the server configuration, the type of server connection to configure (see [[Server Resources]]), and the host or hosts that will be used for the new configuration.<br />
</td><br />
<td><br />
[[Image:Configure_new_server.png|thumb|right|300px|'''Figure 2: "Configure New Server" dialog''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Editing Server Configuration ==<br />
<br />
After creating a new server or choosing ''Edit Server'' from the Server Browser dialog, the "Configure Server" dialog opens.<br />
<br />
Note that the Configure Server dialog will display server configurations loaded from ''default_servers.pvsc'' in a "read-only" state.<br />
<br />
=== Command Startup ===<br />
<br />
<table><br />
<tr><br />
<td><br />
For new server configurations, the dialog defaults to a ''Command'' startup configuration. In this case ParaView will run an external command to start the server. The external command will be run using exec() (Posix systems) or CreateProcess() (Win32), so shell-specific functionality such as redirection or "&" cannot be used (unless you invoke a specific shell directly).<br />
<br />
The external command cannot block while the server is running, it should start the server in the background and return.<br />
<br />
Users may configure a delay between the time the startup command returns and the time that the client attempts connection.<br />
<br />
A set of predefined and user-defined environment variables are used to communicate connection parameters to the command, see [[Server Configuration]] for details on variables and site-specific configuration.<br />
<br />
</td><br />
<td><br />
[[Image:Configure_command_startup.png|thumb|right|300px|'''Figure 3: "Configure Server" dialog, specifying "Command" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
=== Manual Startup ===<br />
<br />
<table width="100%"><br />
<tr><br />
<td><br />
Users who prefer to start servers manually can specify as such in the "Configure Server" dialog. In this case, the user must ensure that the server(s) are running before attempting to connect with the ParaView client.<br />
</td><br />
<td><br />
[[Image:Configure_manual_startup.png|thumb|right|300px|'''Figure 4: "Configure Server" dialog, specifying "Manual" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Sample Startup Commands ==<br />
<br />
=== Win32 ===<br />
<br />
To start a server on the local host:<br />
<br />
cmd /c start /b pvserver --server-port=%PV_SERVER_PORT% --use-offscreen-rendering<br />
<br />
''cmd /c start /b'' is used to start pvserver in the background on Win32.<br />
<br />
=== GNU/Linux ===<br />
<br />
To start a server on the local host:<br />
<br />
python -c "import os; os.system('pvserver --use-offscreen-rendering &')" <br />
<br />
... in this case, os.system() allows us to use the shell "&" to start pvserver in the background.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Starting_the_server&diff=7235Starting the server2006-10-04T22:05:52Z<p>Tshead: /* GNU/Linux */</p>
<hr />
<div>== Overview ==<br />
<br />
Past versions of ParaView have required users to start client and server manually, specifying connection protocols and parameters at the command-line. ParaView3 improves the user experience by allowing users to start the client and make/break server connections using the client's graphical user interface.<br />
<br />
For this functionality to work, ParaView must be properly configured to start remote servers. Startup procedures are expected to vary from site-to-site, due to differences in network topology, firewalls, address translation, logging requirements, etc. To accomodate this, a flexible mechanism allows users to run arbitrary commands on a per-server and/or per-connection-scheme basis at server startup.<br />
<br />
<br />
== Managing Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
The collection of configured servers can be accessed through the "Server Browser" dialog, which presents a listing of servers that are already configured. The Server Browser dialog is displayed whenever you:<br />
<br />
* Select the ''File > Connect'' menu item or corresponding toolbar button.<br />
* Choose the ''File > Open'' menu item or toolbar button and there is no server currently connected.<br />
* Select an item from the ''File > Recent Files'' menu for which there is ''more than one'' possible server configuration that could be used for the item selected.<br />
<br />
The Server Browser dialog contains standard controls for editing, deleting, and adding new server configurations. Additions and changes to configured servers are stored in per-user preferences. Server configuration data can also be saved and loaded to the local filesystem in XML format using the provided controls.<br />
<br />
If a server configuration file named ''default_servers.pvsc'' is located in the same directory as the ParaView binary executable, it will be loaded at startup time. Per-user preferences are loaded after ''default_servers.pvsc'', so they can override its contents. Note that additions, deletions, and changes to servers never alter the contents of ''default_servers.pvsc''. See [[Server Configuration]] for details on the XML schema used by ''default_servers.pvsc''.<br />
<br />
</td><br />
<td><br />
[[Image:Server browser.png|thumb|right|200px|'''Figure 1: "Server Browser" dialog displaying the list of configured servers.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Configuring New Servers ==<br />
<br />
<table><br />
<tr><br />
<td><br />
If the user chooses ''Add Server'' in the "Manage Servers" dialog or chooses an item from the ''File > Recent Files'' menu for which a server configuration doesn't exist, the "Configure New Server" dialog opens. The user is prompted to select a name for the server configuration, the type of server connection to configure (see [[Server Resources]]), and the host or hosts that will be used for the new configuration.<br />
</td><br />
<td><br />
[[Image:Configure_new_server.png|thumb|right|300px|'''Figure 2: "Configure New Server" dialog''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Editing Server Configuration ==<br />
<br />
After creating a new server or choosing ''Edit Server'' from the Server Browser dialog, the "Configure Server" dialog opens.<br />
<br />
Note that the Configure Server dialog will display server configurations loaded from ''default_servers.pvsc'' in a "read-only" state.<br />
<br />
=== Command Startup ===<br />
<br />
<table><br />
<tr><br />
<td><br />
For new server configurations, the dialog defaults to a ''Command'' startup configuration. In this case ParaView will run an external command to start the server. The external command will be run using exec() (Posix systems) or CreateProcess() (Win32), so shell-specific functionality such as redirection or "&" cannot be used (unless you invoke a specific shell directly).<br />
<br />
The external command cannot block while the server is running, it should start the server in the background and return.<br />
<br />
Users may configure a delay between the time the startup command returns and the time that the client attempts connection.<br />
<br />
A set of predefined and user-defined environment variables are used to communicate connection parameters to the command, see [[Server Configuration]] for details on variables and site-specific configuration.<br />
<br />
</td><br />
<td><br />
[[Image:Configure_command_startup.png|thumb|right|300px|'''Figure 3: "Configure Server" dialog, specifying "Command" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
=== Manual Startup ===<br />
<br />
<table width="100%"><br />
<tr><br />
<td><br />
Users who prefer to start servers manually can specify as such in the "Configure Server" dialog. In this case, the user must ensure that the server(s) are running before attempting to connect with the ParaView client.<br />
</td><br />
<td><br />
[[Image:Configure_manual_startup.png|thumb|right|300px|'''Figure 4: "Configure Server" dialog, specifying "Manual" startup.''']]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Sample Startup Commands ==<br />
<br />
=== Win32 ===<br />
<br />
To start a server on the local host:<br />
<br />
cmd /c start /b pvserver --server-port=%PV_SERVER_PORT% --use-offscreen-rendering<br />
<br />
''cmd /c start /b'' is used to start pvserver in the background.<br />
<br />
=== GNU/Linux ===<br />
<br />
To start a server on the local host:<br />
<br />
python -c "import os; os.system('pvserver --use-offscreen-rendering &')" <br />
<br />
... in this case, os.system() allows us to use the shell "&" to start pvserver in the background.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Testing_design&diff=7223Testing design2006-10-03T15:24:10Z<p>Tshead: </p>
<hr />
<div>== Overview ==<br />
<br />
The VTK and ParaView projects have a long history of regression testing using the tools (ctest, dashboards, etc) provided by CMake. With the move to use Qt as the user interface toolkit in ParaView, it is necessary to revisit the manner in which application / user interface testing is performed. Several testing frameworks (QtTest, Squish, KDExecutor) have been evaluated, but do not meet ParaView's needs due to licensing and other issues. Thus, a new testing framework has been created - this document is intended to describe the new framework in sufficient detail to allow outside contribution.<br />
<br />
== Requirements ==<br />
<br />
* The framework must have an open source license consistent with the ParaView / VTK license. Rationale: to allow all ParaView users to contribute and run test cases.<br />
* The framework should support easy test case creation to encourage user-contributed tests and bug reporting.<br />
* The framework should allow for multiple forms of validation whether a test passes or fails, including-but-not-limited to image-based validation.<br />
* The framework should support test cases that can be recorded as scripts. Rationale: a test case recorded as a script can apply complex logic for quantitative verification and validation of results. For example, a scripted test case could check the values of internal data structures during playback, instead of relying on image-based validation.<br />
* The framework should support test cases that can be recorded as low-level "metafiles". Rationale: simplicity, reduce dependencies on any given script engine for testing.<br />
* Where possible, test-cases should continue to play-back correctly despite modifications to the user interface.<br />
* To reduce developer burden, the framework should be as unintrusive as possible. In particular, it should be possible to use the framework with existing code and interfaces built using Qt Designer, and the framework should not require that the developer use "special" widgets, multiple inheritance, or the like.<br />
<br />
== Design Challenges ==<br />
<br />
=== Low-Level vs. High-Level Events ===<br />
<br />
In theory, all user interaction with a graphical user interface can be broken-down into a handful of low-level "events": mouse button press, mouse button release, mouse movement, key press, and key release. Recording the low-level events and their parameters as they happen for recording, then synthesizing the same events in order for playback, will put the application into the same state. In practice, this approach does not work well due to differences in user interface "skins", platform, hardware, and operating environment:<br />
<br />
* Differences in window manager between platforms (or even on the same platform, due to user choices) may cause the sizes and arrangement of windows to vary between test case recording and playback.<br />
* Due to user interface skinning or platform specific look-and-feel, the sizes of widgets may very, even if the top-level window is consistently sized. As an example, the width of a splitter bar may vary by a few pixels between two platforms. During playback of a test case where the user resizes a splitter, this could cause the mouse to "miss" the splitter, sending the subsequent mouse movement events into adjacent controls instead of to the splitter where they belong. Differences in font size will affect the size of a menu. Internationalization can radically change the size and layout of widgets.<br />
* When recording typical user interaction with a file dialog, the test case would include some combination of scrollbar movement and double-clicks as the user navigated through their filesystem. Unfortunately, this recording would be heavily dependent on the contents of the filesystem - nearly any change in filesystem contents between recording and playback will cause the test to fail, since filenames would be in different locations relative to the mouse.<br />
* A recording of user interaction with a spin button would fail during playback if the spin button is replaced with a slider, despite the fact that both represent an integer quantity.<br />
<br />
For these and many other similar issues, it isn't enough that a test case record what the user ''did'' - a test case should record what the user ''intended''. Thus, test case recording and playback becomes a case of mapping between low level user interface events and ''high-level'' events - rather than recording a button activation as a mouse press event followed by a mouse release event at such-and-such coordinates, a single high-level "button activation" event can be recorded, so that the correct button can be activated during playback, regardless of its screen coordinates. Similarly, all of the mouse clicks and scrolling within a file dialog can be replaced by a single "file selected" event that includes the file name as a parameter - during playback, the correct file can be selected regardless of any changes to the underlying filesystem. When recording interaction with a spin button, the series of mouse-clicks and keyboard input can be replaced with a single "set integer" event that includes the final value as a parameter - during playback, the "set integer" event can be interpreted by any widget that represents integers (spin buttons, sliders, dials, etc), not just the type of widget used to record the test.<br />
<br />
=== Widget Naming ===<br />
<br />
While the notion of mapping between low-level and high-level events is straightforward, one problem remains - how to provide a serializable ''name'' for widgets so that high-level events can be directed to the correct widget during playback. It is typical to use pointers or references to access Qt widgets at runtime, but these are obviously inadequate as serializable identifiers. The main problem is with generating globally-unique names, while allowing for reasonable changes to the user interface without breaking test cases. As an example, a test recorded on one system may be played-back on another, with a different configuration of docked / floating toolbars. Several alternatives have been discussed:<br />
<br />
* Flat - Assign a globally-unique name to every widget. Pros: test cases work no matter how the UI is rearranged. Cons: Developers must explicitly name everything, names quickly become unwieldy, QtDesigner limits widget names (e.g. can't contain slashes), and QtDesigner-generated intance variables will share the long, unwieldy names.<br />
* The MS Way - Same as "Flat", only use 128-bit UUIDs as identifiers. Insert Homer Simpson-like shudder here ...<br />
* Widget Hierarchy - Use the Qt widget hierarchy to generate unique names. Pros: developers can use straightforward names for widgets in Qt designer, and only have to explicitly name top-level objects like dialogs. Cons: rearranging the widget hierarchy breaks test cases, e.g. floating/docking windows.<br />
* The [http://www.k-3d.org K-3D Way] - Use a hierarchical naming scheme, but make it orthogonal to the Qt widget hierachy. Pros: same as "Widget Hierarchy", plus floating and docking windows no longer break test cases. Cons: since this is a separate hierarchy, it has to be maintained at runtime, e.g. by explicitly registering widgets with some central manager, implying a highly-intrusive mechanism of custom widgets or the like.<br />
<br />
After considering these options it was decided that the framework would use the "Widget Hierarchy" method, generating widget names by walking the Qt widget hierarchy, concatenating object names (separated by slashes) into a hierarchical "path" string. Although this method is especially brittle in the face of UI modifications, it requires the least developer effort and integrates well with custom user interfaces and interfaces created with Qt designer.<br />
<br />
== Design ==<br />
<br />
=== Recording ===<br />
<br />
Test case recording centers around the ''pqWidgetEventTranslator'' abstract interface class. Derivatives of this class are responsible for converting low-level Qt events ("mouse move", "button down", "button up", etc) into the high-level events (e.g: "button activated") that can be serialized and played back. pqWidgetEventTranslator derivatives may be particular to a specific widget type, such as ''pqComboBoxEventTranslator'', or may represent a class of related widgets, such as ''pqAbstractSliderEventTranslator'', which can translate events for any widget that derives from QAbstractSlider, including QDial, QScrollBar, and QSlider. pqWidgetEventTranslator derivatives implement the translateEvent() method, where they determine whether they can handle a Qt event, and if they can, convert it into a high-level event which consists of two strings: a ''command'', and the corresponding command ''arguments'' (which may be empty). The translator then emits the recordEvent() signal one-or-more times to pass the high-level event(s) to its container. It is intended that the test framework eventually include pqEventWidgetTranslator derivatives for all "stock" Qt widgets.<br />
<br />
A collection of pqWidgetEventTranslator objects is maintained at runtime by an instance of ''pqEventTranslator''. pqEventTranslator hooks itself into the Qt event loop as a top-level event filter, so it receives every Qt event that occurs at runtime for the entire application. pqEventTranslator passes the Qt event to each of its pqWidgetEventTranslator instances in-turn, until one of the instances signals that the event has been "consumed". When a pqWidgetEventTranslator emits a high-level event, the event is "caught" by the pqEventTranslator instance and combined with the serializable address of the widget to which the high-level event applies. The three strings (address, command, and arguments) of the complete high-level event are emitted from the pqEventTranslator as a Qt signal.<br />
<br />
The high-level event emitted from pqEventTranslator may be caught by any ''observer'' with the correct Qt slot. It is up to the observer(s) to serialize the high-level event for later playback. At this time the framework includes two observers, ''pqEventObserverStdout'' and ''pqEventObserverXML'', which serialize the high-level events to stdout and an XML file respectively. Developers can create their own observers to implement custom functionality, such as serializing events to a logfile, a Python script, etc.<br />
<br />
=== Playback ===<br />
<br />
Test case playback is basically a mirror-image of recording. The ''pqEventSource'' provides an abstract interface for objects capable of providing a "stream" of high-level events. The ''pqXMLEventSource'' provides a concrete implementation of pqEventSource, and is capable of reading the XML files generated by pqEventObserverXML.<br />
<br />
The ''pqEventPlayer'' class maintains a collection of ''pqWidgetEventPlayer'' objects that handle translation from high-level events to low-level events. An instance of ''pqEventDispatcher'' retrieves events from a pqEventSource, handing them off to an instance of pqEventPlayer for playback.<br />
<br />
Derivatives of the ''pqWidgetEventPlayer'' abstract interface class are responsible for mapping high-level events back into low-level Qt events (or direct widget manipulation). Note that there is '''not''' a one-to-one correspondence between pqWidgetEventTranslator and pqWidgetEventPlayer classes - a single pqAbstractIntEventPlayer object is capable of handling events generated by both pqSpinBoxEventTranslator and pqAbstractSliderEventTranslator, because the two translators map dissimilar Qt events into a single, abstract "set_int" event.<br />
<br />
pqEventPlayer maintains a collection of pqWidgetEventPlayer objects, and as with pqEventTranslator, the set of pqWidgetEventPlayer objects can be instantiated by the developer or by pqEventTranslator, or both. Each high-level event is encoded as three strings(address, command, and arguments), which are fed to pqEventPlayer::playEvent(). pqEventPlayer decodes the address string and uses it to lookup the corresponding widget. The high-level event and widget are then passed to each pqWidgetEventPlayer in-turn, until one of them signals that the event has been handled.<br />
<br />
=== Extensions ===<br />
<br />
The test framework can be extended through the creation of custom components. To store high-level events to a custom format or device, the developer creates an observer class with a correctly-prototyped slot to receive events from pqEventTranslator. To play the data back, a corresponding pqEventSource derivative is created that can read the data.<br />
<br />
Support for test case recording and playback of custom widgets is handled by creating custom derivatives of pqWidgetEventTranslator and pqWidgetEventPlayer, then adding instances of those custom derivatives to pqEventTranslator and pqEventPlayer, respectively. pqEventTranslator and pqEventPlayer also have methods that instantiate all of the "built in" translators and players that are part of the framework. Because translators and players are executed in-order until a given event has been handled, the developer can "override" builtin translators/players by adding their custom components first.<br />
<br />
=== Outstanding Issues ===<br />
<br />
A significant issue with the design of the framework is the problem of modality - in general, dispatchers cannot assume that a call to pqEventPlayer::playEvent() will return immediately, since the event playback may cause a modal dialog or a widget-generated context menu to be shown. In these cases playEvent() will not return until the dialog is closed or the context menu is hidden, yet the test framework must continue dispatching events or there will never be any simulated user input to close the dialog or choose an item from the menu! For this reason pqEventDispatcher relies on the QAbstractEventDispatcher::aboutToBlock() signal to force asynchronous dispatching of events. Other methods of handling event dispatching have been tried, e.g ''pqThreadedEventDispatcher'', and we consider this to be an area for further development.<br />
<br />
A second tricky problem has been the mapping of high-level events to low-level Qt events for playback. In a nutshell, receiving useful events for recording is easy, because the API of a user interface toolkit such as Qt is fundamentally there to enable a client application to ''receive'' information about user interaction. Playback is more difficult because the synthesis of simulated user input is a highly specialized use case that is generally not supported or encouraged by the public API. This can lead to complex code, and generally requires an understanding of the internal implementation details of Qt widgets: on one hand, playing-back a button activation is simple, because the QAbstractButton::click() method is part of the API, while playing-back a menu activation is complex, because there is no comparable method for menu items. In the latter case, the implementation must synthesize low-level Qt events to simulate the corresponding user interaction.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Testing_design&diff=7222Testing design2006-10-03T15:22:40Z<p>Tshead: /* Extensions */</p>
<hr />
<div>== Overview ==<br />
<br />
The VTK and ParaView projects have a long history of regression testing using the tools (ctest, dashboards, etc) provided by CMake. With the move to use Qt as the user interface toolkit in ParaView, it is necessary to revisit the manner in which application / user interface testing is performed. Several testing frameworks (QtTest, Squish, KDExecutor) have been evaluated, but do not meet ParaView's needs due to licensing and other issues. Thus, a new testing framework has been created - this document is intended to describe the new framework in sufficient detail to allow outside contribution.<br />
<br />
== Requirements ==<br />
<br />
* The framework must have an open source license consistent with the ParaView / VTK license. Rationale: to allow all ParaView users to contribute and run test cases.<br />
* The framework should support easy test case creation to encourage user-contributed tests and bug reporting.<br />
* The framework should allow for multiple forms of validation whether a test passes or fails, including-but-not-limited to image-based validation.<br />
* The framework should support test cases that can be recorded as scripts. Rationale: a test case recorded as a script can apply complex logic for quantitative verification and validation of results. For example, a scripted test case could check the values of internal data structures during playback, instead of relying on image-based validation.<br />
* The framework should support test cases that can be recorded as low-level "metafiles". Rationale: simplicity, reduce dependencies on any given script engine for testing.<br />
* Where possible, test-cases should continue to play-back correctly despite modifications to the user interface.<br />
* To reduce developer burden, the framework should be as unintrusive as possible. In particular, it should be possible to use the framework with existing code and interfaces built using Qt Designer, and the framework should not require that the developer use "special" widgets, multiple inheritance, or the like.<br />
<br />
== Design Challenges ==<br />
<br />
=== Low-Level vs. High-Level Events ===<br />
<br />
In theory, all user interaction with a graphical user interface can be broken-down into a handful of low-level "events": mouse button press, mouse button release, mouse movement, key press, and key release. Recording the low-level events and their parameters as they happen for recording, then synthesizing the same events in order for playback, will put the application into the same state. In practice, this approach does not work well due to differences in user interface "skins", platform, hardware, and operating environment:<br />
<br />
* Differences in window manager between platforms (or even on the same platform, due to user choices) may cause the sizes and arrangement of windows to vary between test case recording and playback.<br />
* Due to user interface skinning or platform specific look-and-feel, the sizes of widgets may very, even if the top-level window is consistently sized. As an example, the width of a splitter bar may vary by a few pixels between two platforms. During playback of a test case where the user resizes a splitter, this could cause the mouse to "miss" the splitter, sending the subsequent mouse movement events into adjacent controls instead of to the splitter where they belong. Differences in font size will affect the size of a menu. Internationalization can radically change the size and layout of widgets.<br />
* When recording typical user interaction with a file dialog, the test case would include some combination of scrollbar movement and double-clicks as the user navigated through their filesystem. Unfortunately, this recording would be heavily dependent on the contents of the filesystem - nearly any change in filesystem contents between recording and playback will cause the test to fail, since filenames would be in different locations relative to the mouse.<br />
* A recording of user interaction with a spin button would fail during playback if the spin button is replaced with a slider, despite the fact that both represent an integer quantity.<br />
<br />
For these and many other similar issues, it isn't enough that a test case record what the user ''did'' - a test case should record what the user ''intended''. Thus, test case recording and playback becomes a case of mapping between low level user interface events and ''high-level'' events - rather than recording a button activation as a mouse press event followed by a mouse release event at such-and-such coordinates, a single high-level "button activation" event can be recorded, so that the correct button can be activated during playback, regardless of its screen coordinates. Similarly, all of the mouse clicks and scrolling within a file dialog can be replaced by a single "file selected" event that includes the file name as a parameter - during playback, the correct file can be selected regardless of any changes to the underlying filesystem. When recording interaction with a spin button, the series of mouse-clicks and keyboard input can be replaced with a single "set integer" event that includes the final value as a parameter - during playback, the "set integer" event can be interpreted by any widget that represents integers (spin buttons, sliders, dials, etc), not just the type of widget used to record the test.<br />
<br />
=== Widget Naming ===<br />
<br />
While the notion of mapping between low-level and high-level events is straightforward, one problem remains - how to provide a serializable ''name'' for widgets so that high-level events can be directed to the correct widget during playback. It is typical to use pointers or references to access Qt widgets at runtime, but these are obviously inadequate as serializable identifiers. The main problem is with generating globally-unique names, while allowing for reasonable changes to the user interface without breaking test cases. As an example, a test recorded on one system may be played-back on another, with a different configuration of docked / floating toolbars. Several alternatives have been discussed:<br />
<br />
* Flat - Assign a globally-unique name to every widget. Pros: test cases work no matter how the UI is rearranged. Cons: Developers must explicitly name everything, names quickly become unwieldy, QtDesigner limits widget names (e.g. can't contain slashes), and QtDesigner-generated intance variables will share the long, unwieldy names.<br />
* The MS Way - Same as "Flat", only use 128-bit UUIDs as identifiers. Insert Homer Simpson-like shudder here ...<br />
* Widget Hierarchy - Use the Qt widget hierarchy to generate unique names. Pros: developers can use straightforward names for widgets in Qt designer, and only have to explicitly name top-level objects like dialogs. Cons: rearranging the widget hierarchy breaks test cases, e.g. floating/docking windows.<br />
* The [http://www.k-3d.org K-3D Way] - Use a hierarchical naming scheme, but make it orthogonal to the Qt widget hierachy. Pros: same as "Widget Hierarchy", plus floating and docking windows no longer break test cases. Cons: since this is a separate hierarchy, it has to be maintained at runtime, e.g. by explicitly registering widgets with some central manager, implying a highly-intrusive mechanism of custom widgets or the like.<br />
<br />
After considering these options it was decided that the framework would use the "Widget Hierarchy" method, generating widget names by walking the Qt widget hierarchy, concatenating object names (separated by slashes) into a hierarchical "path" string. Although this method is especially brittle in the face of UI modifications, it requires the least developer effort and integrates well with custom user interfaces and interfaces created with Qt designer.<br />
<br />
== Design ==<br />
<br />
=== Recording ===<br />
<br />
Test case recording centers around the ''pqWidgetEventTranslator'' abstract interface class. Derivatives of this class are responsible for converting low-level Qt events ("mouse move", "button down", "button up", etc) into the high-level events (e.g: "button activated") that can be serialized and played back. pqWidgetEventTranslator derivatives may be particular to a specific widget type, such as ''pqComboBoxEventTranslator'', or may represent a class of related widgets, such as ''pqAbstractSliderEventTranslator'', which can translate events for any widget that derives from QAbstractSlider, including QDial, QScrollBar, and QSlider. pqWidgetEventTranslator derivatives implement the translateEvent() method, where they determine whether they can handle a Qt event, and if they can, convert it into a high-level event which consists of two strings: a ''command'', and the corresponding command ''arguments'' (which may be empty). The translator then emits the recordEvent() signal one-or-more times to pass the high-level event(s) to its container. It is intended that the test framework eventually include pqEventWidgetTranslator derivatives for all "stock" Qt widgets.<br />
<br />
A collection of pqWidgetEventTranslator objects is maintained at runtime by an instance of ''pqEventTranslator''. pqEventTranslator hooks itself into the Qt event loop as a top-level event filter, so it receives every Qt event that occurs at runtime for the entire application. pqEventTranslator passes the Qt event to each of its pqWidgetEventTranslator instances in-turn, until one of the instances signals that the event has been "consumed". When a pqWidgetEventTranslator emits a high-level event, the event is "caught" by the pqEventTranslator instance and combined with the serializable address of the widget to which the high-level event applies. The three strings (address, command, and arguments) of the complete high-level event are emitted from the pqEventTranslator as a Qt signal.<br />
<br />
The high-level event emitted from pqEventTranslator may be caught by any ''observer'' with the correct Qt slot. It is up to the observer(s) to serialize the high-level event for later playback. At this time the framework includes two observers, ''pqEventObserverStdout'' and ''pqEventObserverXML'', which serialize the high-level events to stdout and an XML file respectively. Developers can create their own observers to implement custom functionality, such as serializing events to a logfile, a Python script, etc.<br />
<br />
=== Playback ===<br />
<br />
Test case playback is basically a mirror-image of recording. The ''pqEventSource'' provides an abstract interface for objects capable of providing a "stream" of high-level events. The ''pqXMLEventSource'' provides a concrete implementation of pqEventSource, and is capable of reading the XML files generated by pqEventObserverXML.<br />
<br />
The ''pqEventPlayer'' class maintains a collection of ''pqWidgetEventPlayer'' objects that handle translation from high-level events to low-level events. An instance of ''pqEventDispatcher'' retrieves events from a pqEventSource, handing them off to an instance of pqEventPlayer for playback.<br />
<br />
Derivatives of the ''pqWidgetEventPlayer'' abstract interface class are responsible for mapping high-level events back into low-level Qt events (or direct widget manipulation). Note that there is '''not''' a one-to-one correspondence between pqWidgetEventTranslator and pqWidgetEventPlayer classes - a single pqAbstractIntEventPlayer object is capable of handling events generated by both pqSpinBoxEventTranslator and pqAbstractSliderEventTranslator, because the two translators map dissimilar Qt events into a single, abstract "set_int" event.<br />
<br />
pqEventPlayer maintains a collection of pqWidgetEventPlayer objects, and as with pqEventTranslator, the set of pqWidgetEventPlayer objects can be instantiated by the developer or by pqEventTranslator, or both. Each high-level event is encoded as three strings(address, command, and arguments), which are fed to pqEventPlayer::playEvent(). pqEventPlayer decodes the address string and uses it to lookup the corresponding widget. The high-level event and widget are then passed to each pqWidgetEventPlayer in-turn, until one of them signals that the event has been handled.<br />
<br />
=== Extensions ===<br />
<br />
The test framework can be extended through the creation of custom components. To store high-level events to a custom format or device, the developer creates an observer class with a correctly-prototyped slot to receive events from pqEventTranslator. To play the data back, a corresponding pqEventSource derivative is created that can read the data.<br />
<br />
Support for test case recording and playback of custom widgets is handled by creating custom derivatives of pqWidgetEventTranslator and pqWidgetEventPlayer, then adding instances of those custom derivatives to pqEventTranslator and pqEventPlayer, respectively. pqEventTranslator and pqEventPlayer also have methods that instantiate all of the "built in" translators and players that are part of the framework. Because translators and players are executed in-order until a given event has been handled, the developer can "override" builtin translators/players by adding their custom components first.<br />
<br />
=== Outstanding Issues ===<br />
<br />
A significant issue with the design of the framework is the problem of modality - in general, dispatchers cannot assume that a call to pqEventPlayer::playEvent() will return immediately, since the event playback may cause a modal dialog or a widget-generated context menu to be shown. In these cases playEvent() will not return until the dialog is closed or the context menu is hidden, yet the test framework must continue dispatching events or there will never be any simulated user input to close the dialog or choose an item from the menu! For this reason pqEventDispatcher relies on the QAbstractEventDispatcher::aboutToBlock() signal to force asynchronous dispatching of events. Other methods of handling event dispatching have been tried, e.g ''pqThreadedEventDispatcher'', and we consider this to be an area for further development.<br />
<br />
== Implementation Challenges ==<br />
<br />
The main challenge in implementing the framework has been the mapping of high-level events to low-level Qt events for playback. In a nutshell, receiving useful events for recording is easy, because the API of a user interface toolkit such as Qt is fundamentally there to enable a client application to ''receive'' information about user interaction. Playback is more difficult because the synthesis of simulated user input is a highly specialized use case that is generally not supported or encouraged by the public API. This can lead to complex code, and generally requires an understanding of the internal implementation details of Qt widgets: on one hand, playing-back a button activation is simple, because the QAbstractButton::click() method is part of the API, while playing-back a menu activation is complex, because there is no comparable method for menu items. In the latter case, the implementation must synthesize enough low-level Qt events to simulate the corresponding user interaction.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Testing_design&diff=7221Testing design2006-10-03T15:09:54Z<p>Tshead: /* Playback */</p>
<hr />
<div>== Overview ==<br />
<br />
The VTK and ParaView projects have a long history of regression testing using the tools (ctest, dashboards, etc) provided by CMake. With the move to use Qt as the user interface toolkit in ParaView, it is necessary to revisit the manner in which application / user interface testing is performed. Several testing frameworks (QtTest, Squish, KDExecutor) have been evaluated, but do not meet ParaView's needs due to licensing and other issues. Thus, a new testing framework has been created - this document is intended to describe the new framework in sufficient detail to allow outside contribution.<br />
<br />
== Requirements ==<br />
<br />
* The framework must have an open source license consistent with the ParaView / VTK license. Rationale: to allow all ParaView users to contribute and run test cases.<br />
* The framework should support easy test case creation to encourage user-contributed tests and bug reporting.<br />
* The framework should allow for multiple forms of validation whether a test passes or fails, including-but-not-limited to image-based validation.<br />
* The framework should support test cases that can be recorded as scripts. Rationale: a test case recorded as a script can apply complex logic for quantitative verification and validation of results. For example, a scripted test case could check the values of internal data structures during playback, instead of relying on image-based validation.<br />
* The framework should support test cases that can be recorded as low-level "metafiles". Rationale: simplicity, reduce dependencies on any given script engine for testing.<br />
* Where possible, test-cases should continue to play-back correctly despite modifications to the user interface.<br />
* To reduce developer burden, the framework should be as unintrusive as possible. In particular, it should be possible to use the framework with existing code and interfaces built using Qt Designer, and the framework should not require that the developer use "special" widgets, multiple inheritance, or the like.<br />
<br />
== Design Challenges ==<br />
<br />
=== Low-Level vs. High-Level Events ===<br />
<br />
In theory, all user interaction with a graphical user interface can be broken-down into a handful of low-level "events": mouse button press, mouse button release, mouse movement, key press, and key release. Recording the low-level events and their parameters as they happen for recording, then synthesizing the same events in order for playback, will put the application into the same state. In practice, this approach does not work well due to differences in user interface "skins", platform, hardware, and operating environment:<br />
<br />
* Differences in window manager between platforms (or even on the same platform, due to user choices) may cause the sizes and arrangement of windows to vary between test case recording and playback.<br />
* Due to user interface skinning or platform specific look-and-feel, the sizes of widgets may very, even if the top-level window is consistently sized. As an example, the width of a splitter bar may vary by a few pixels between two platforms. During playback of a test case where the user resizes a splitter, this could cause the mouse to "miss" the splitter, sending the subsequent mouse movement events into adjacent controls instead of to the splitter where they belong. Differences in font size will affect the size of a menu. Internationalization can radically change the size and layout of widgets.<br />
* When recording typical user interaction with a file dialog, the test case would include some combination of scrollbar movement and double-clicks as the user navigated through their filesystem. Unfortunately, this recording would be heavily dependent on the contents of the filesystem - nearly any change in filesystem contents between recording and playback will cause the test to fail, since filenames would be in different locations relative to the mouse.<br />
* A recording of user interaction with a spin button would fail during playback if the spin button is replaced with a slider, despite the fact that both represent an integer quantity.<br />
<br />
For these and many other similar issues, it isn't enough that a test case record what the user ''did'' - a test case should record what the user ''intended''. Thus, test case recording and playback becomes a case of mapping between low level user interface events and ''high-level'' events - rather than recording a button activation as a mouse press event followed by a mouse release event at such-and-such coordinates, a single high-level "button activation" event can be recorded, so that the correct button can be activated during playback, regardless of its screen coordinates. Similarly, all of the mouse clicks and scrolling within a file dialog can be replaced by a single "file selected" event that includes the file name as a parameter - during playback, the correct file can be selected regardless of any changes to the underlying filesystem. When recording interaction with a spin button, the series of mouse-clicks and keyboard input can be replaced with a single "set integer" event that includes the final value as a parameter - during playback, the "set integer" event can be interpreted by any widget that represents integers (spin buttons, sliders, dials, etc), not just the type of widget used to record the test.<br />
<br />
=== Widget Naming ===<br />
<br />
While the notion of mapping between low-level and high-level events is straightforward, one problem remains - how to provide a serializable ''name'' for widgets so that high-level events can be directed to the correct widget during playback. It is typical to use pointers or references to access Qt widgets at runtime, but these are obviously inadequate as serializable identifiers. The main problem is with generating globally-unique names, while allowing for reasonable changes to the user interface without breaking test cases. As an example, a test recorded on one system may be played-back on another, with a different configuration of docked / floating toolbars. Several alternatives have been discussed:<br />
<br />
* Flat - Assign a globally-unique name to every widget. Pros: test cases work no matter how the UI is rearranged. Cons: Developers must explicitly name everything, names quickly become unwieldy, QtDesigner limits widget names (e.g. can't contain slashes), and QtDesigner-generated intance variables will share the long, unwieldy names.<br />
* The MS Way - Same as "Flat", only use 128-bit UUIDs as identifiers. Insert Homer Simpson-like shudder here ...<br />
* Widget Hierarchy - Use the Qt widget hierarchy to generate unique names. Pros: developers can use straightforward names for widgets in Qt designer, and only have to explicitly name top-level objects like dialogs. Cons: rearranging the widget hierarchy breaks test cases, e.g. floating/docking windows.<br />
* The [http://www.k-3d.org K-3D Way] - Use a hierarchical naming scheme, but make it orthogonal to the Qt widget hierachy. Pros: same as "Widget Hierarchy", plus floating and docking windows no longer break test cases. Cons: since this is a separate hierarchy, it has to be maintained at runtime, e.g. by explicitly registering widgets with some central manager, implying a highly-intrusive mechanism of custom widgets or the like.<br />
<br />
After considering these options it was decided that the framework would use the "Widget Hierarchy" method, generating widget names by walking the Qt widget hierarchy, concatenating object names (separated by slashes) into a hierarchical "path" string. Although this method is especially brittle in the face of UI modifications, it requires the least developer effort and integrates well with custom user interfaces and interfaces created with Qt designer.<br />
<br />
== Design ==<br />
<br />
=== Recording ===<br />
<br />
Test case recording centers around the ''pqWidgetEventTranslator'' abstract interface class. Derivatives of this class are responsible for converting low-level Qt events ("mouse move", "button down", "button up", etc) into the high-level events (e.g: "button activated") that can be serialized and played back. pqWidgetEventTranslator derivatives may be particular to a specific widget type, such as ''pqComboBoxEventTranslator'', or may represent a class of related widgets, such as ''pqAbstractSliderEventTranslator'', which can translate events for any widget that derives from QAbstractSlider, including QDial, QScrollBar, and QSlider. pqWidgetEventTranslator derivatives implement the translateEvent() method, where they determine whether they can handle a Qt event, and if they can, convert it into a high-level event which consists of two strings: a ''command'', and the corresponding command ''arguments'' (which may be empty). The translator then emits the recordEvent() signal one-or-more times to pass the high-level event(s) to its container. It is intended that the test framework eventually include pqEventWidgetTranslator derivatives for all "stock" Qt widgets.<br />
<br />
A collection of pqWidgetEventTranslator objects is maintained at runtime by an instance of ''pqEventTranslator''. pqEventTranslator hooks itself into the Qt event loop as a top-level event filter, so it receives every Qt event that occurs at runtime for the entire application. pqEventTranslator passes the Qt event to each of its pqWidgetEventTranslator instances in-turn, until one of the instances signals that the event has been "consumed". When a pqWidgetEventTranslator emits a high-level event, the event is "caught" by the pqEventTranslator instance and combined with the serializable address of the widget to which the high-level event applies. The three strings (address, command, and arguments) of the complete high-level event are emitted from the pqEventTranslator as a Qt signal.<br />
<br />
The high-level event emitted from pqEventTranslator may be caught by any ''observer'' with the correct Qt slot. It is up to the observer(s) to serialize the high-level event for later playback. At this time the framework includes two observers, ''pqEventObserverStdout'' and ''pqEventObserverXML'', which serialize the high-level events to stdout and an XML file respectively. Developers can create their own observers to implement custom functionality, such as serializing events to a logfile, a Python script, etc.<br />
<br />
=== Playback ===<br />
<br />
Test case playback is basically a mirror-image of recording. The ''pqEventSource'' provides an abstract interface for objects capable of providing a "stream" of high-level events. The ''pqXMLEventSource'' provides a concrete implementation of pqEventSource, and is capable of reading the XML files generated by pqEventObserverXML.<br />
<br />
The ''pqEventPlayer'' class maintains a collection of ''pqWidgetEventPlayer'' objects that handle translation from high-level events to low-level events. An instance of ''pqEventDispatcher'' retrieves events from a pqEventSource, handing them off to an instance of pqEventPlayer for playback.<br />
<br />
Derivatives of the ''pqWidgetEventPlayer'' abstract interface class are responsible for mapping high-level events back into low-level Qt events (or direct widget manipulation). Note that there is '''not''' a one-to-one correspondence between pqWidgetEventTranslator and pqWidgetEventPlayer classes - a single pqAbstractIntEventPlayer object is capable of handling events generated by both pqSpinBoxEventTranslator and pqAbstractSliderEventTranslator, because the two translators map dissimilar Qt events into a single, abstract "set_int" event.<br />
<br />
pqEventPlayer maintains a collection of pqWidgetEventPlayer objects, and as with pqEventTranslator, the set of pqWidgetEventPlayer objects can be instantiated by the developer or by pqEventTranslator, or both. Each high-level event is encoded as three strings(address, command, and arguments), which are fed to pqEventPlayer::playEvent(). pqEventPlayer decodes the address string and uses it to lookup the corresponding widget. The high-level event and widget are then passed to each pqWidgetEventPlayer in-turn, until one of them signals that the event has been handled.<br />
<br />
=== Extensions ===<br />
<br />
The test framework can be extended through the creation of custom components. To store high-level events to a custom format or device, the developer simply needs to create an observer class with a correctly-prototyped slot to receive events from pqEventTranslator. To play custom formats back, a developer simply calls the pqEventPlayer::playEvent() method repeatedly from whatever code suits their purpose, no other integration with the framework is necessary.<br />
<br />
Support for test case recording and playback of custom widgets is handled by creating custom derivatives of pqWidgetEventTranslator and pqWidgetEventPlayer, then adding instances of those custom derivatives to pqEventTranslator and pqEventPlayer, respectively. pqEventTranslator and pqEventPlayer also have methods that instantiate all of the "built in" translators and players that are part of the framework. Because translators and players are executed in-order until a given event has been handled, the developer can "override" builtin translators/players by adding their custom components first.<br />
<br />
== Implementation Challenges ==<br />
<br />
The main challenge in implementing the framework has been the mapping of high-level events to low-level Qt events for playback. In a nutshell, receiving useful events for recording is easy, because the API of a user interface toolkit such as Qt is fundamentally there to enable a client application to ''receive'' information about user interaction. Playback is more difficult because the synthesis of simulated user input is a highly specialized use case that is generally not supported or encouraged by the public API. This can lead to complex code, and generally requires an understanding of the internal implementation details of Qt widgets: on one hand, playing-back a button activation is simple, because the QAbstractButton::click() method is part of the API, while playing-back a menu activation is complex, because there is no comparable method for menu items. In the latter case, the implementation must synthesize enough low-level Qt events to simulate the corresponding user interaction.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=Testing_design&diff=7220Testing design2006-10-03T15:00:37Z<p>Tshead: /* Recording */</p>
<hr />
<div>== Overview ==<br />
<br />
The VTK and ParaView projects have a long history of regression testing using the tools (ctest, dashboards, etc) provided by CMake. With the move to use Qt as the user interface toolkit in ParaView, it is necessary to revisit the manner in which application / user interface testing is performed. Several testing frameworks (QtTest, Squish, KDExecutor) have been evaluated, but do not meet ParaView's needs due to licensing and other issues. Thus, a new testing framework has been created - this document is intended to describe the new framework in sufficient detail to allow outside contribution.<br />
<br />
== Requirements ==<br />
<br />
* The framework must have an open source license consistent with the ParaView / VTK license. Rationale: to allow all ParaView users to contribute and run test cases.<br />
* The framework should support easy test case creation to encourage user-contributed tests and bug reporting.<br />
* The framework should allow for multiple forms of validation whether a test passes or fails, including-but-not-limited to image-based validation.<br />
* The framework should support test cases that can be recorded as scripts. Rationale: a test case recorded as a script can apply complex logic for quantitative verification and validation of results. For example, a scripted test case could check the values of internal data structures during playback, instead of relying on image-based validation.<br />
* The framework should support test cases that can be recorded as low-level "metafiles". Rationale: simplicity, reduce dependencies on any given script engine for testing.<br />
* Where possible, test-cases should continue to play-back correctly despite modifications to the user interface.<br />
* To reduce developer burden, the framework should be as unintrusive as possible. In particular, it should be possible to use the framework with existing code and interfaces built using Qt Designer, and the framework should not require that the developer use "special" widgets, multiple inheritance, or the like.<br />
<br />
== Design Challenges ==<br />
<br />
=== Low-Level vs. High-Level Events ===<br />
<br />
In theory, all user interaction with a graphical user interface can be broken-down into a handful of low-level "events": mouse button press, mouse button release, mouse movement, key press, and key release. Recording the low-level events and their parameters as they happen for recording, then synthesizing the same events in order for playback, will put the application into the same state. In practice, this approach does not work well due to differences in user interface "skins", platform, hardware, and operating environment:<br />
<br />
* Differences in window manager between platforms (or even on the same platform, due to user choices) may cause the sizes and arrangement of windows to vary between test case recording and playback.<br />
* Due to user interface skinning or platform specific look-and-feel, the sizes of widgets may very, even if the top-level window is consistently sized. As an example, the width of a splitter bar may vary by a few pixels between two platforms. During playback of a test case where the user resizes a splitter, this could cause the mouse to "miss" the splitter, sending the subsequent mouse movement events into adjacent controls instead of to the splitter where they belong. Differences in font size will affect the size of a menu. Internationalization can radically change the size and layout of widgets.<br />
* When recording typical user interaction with a file dialog, the test case would include some combination of scrollbar movement and double-clicks as the user navigated through their filesystem. Unfortunately, this recording would be heavily dependent on the contents of the filesystem - nearly any change in filesystem contents between recording and playback will cause the test to fail, since filenames would be in different locations relative to the mouse.<br />
* A recording of user interaction with a spin button would fail during playback if the spin button is replaced with a slider, despite the fact that both represent an integer quantity.<br />
<br />
For these and many other similar issues, it isn't enough that a test case record what the user ''did'' - a test case should record what the user ''intended''. Thus, test case recording and playback becomes a case of mapping between low level user interface events and ''high-level'' events - rather than recording a button activation as a mouse press event followed by a mouse release event at such-and-such coordinates, a single high-level "button activation" event can be recorded, so that the correct button can be activated during playback, regardless of its screen coordinates. Similarly, all of the mouse clicks and scrolling within a file dialog can be replaced by a single "file selected" event that includes the file name as a parameter - during playback, the correct file can be selected regardless of any changes to the underlying filesystem. When recording interaction with a spin button, the series of mouse-clicks and keyboard input can be replaced with a single "set integer" event that includes the final value as a parameter - during playback, the "set integer" event can be interpreted by any widget that represents integers (spin buttons, sliders, dials, etc), not just the type of widget used to record the test.<br />
<br />
=== Widget Naming ===<br />
<br />
While the notion of mapping between low-level and high-level events is straightforward, one problem remains - how to provide a serializable ''name'' for widgets so that high-level events can be directed to the correct widget during playback. It is typical to use pointers or references to access Qt widgets at runtime, but these are obviously inadequate as serializable identifiers. The main problem is with generating globally-unique names, while allowing for reasonable changes to the user interface without breaking test cases. As an example, a test recorded on one system may be played-back on another, with a different configuration of docked / floating toolbars. Several alternatives have been discussed:<br />
<br />
* Flat - Assign a globally-unique name to every widget. Pros: test cases work no matter how the UI is rearranged. Cons: Developers must explicitly name everything, names quickly become unwieldy, QtDesigner limits widget names (e.g. can't contain slashes), and QtDesigner-generated intance variables will share the long, unwieldy names.<br />
* The MS Way - Same as "Flat", only use 128-bit UUIDs as identifiers. Insert Homer Simpson-like shudder here ...<br />
* Widget Hierarchy - Use the Qt widget hierarchy to generate unique names. Pros: developers can use straightforward names for widgets in Qt designer, and only have to explicitly name top-level objects like dialogs. Cons: rearranging the widget hierarchy breaks test cases, e.g. floating/docking windows.<br />
* The [http://www.k-3d.org K-3D Way] - Use a hierarchical naming scheme, but make it orthogonal to the Qt widget hierachy. Pros: same as "Widget Hierarchy", plus floating and docking windows no longer break test cases. Cons: since this is a separate hierarchy, it has to be maintained at runtime, e.g. by explicitly registering widgets with some central manager, implying a highly-intrusive mechanism of custom widgets or the like.<br />
<br />
After considering these options it was decided that the framework would use the "Widget Hierarchy" method, generating widget names by walking the Qt widget hierarchy, concatenating object names (separated by slashes) into a hierarchical "path" string. Although this method is especially brittle in the face of UI modifications, it requires the least developer effort and integrates well with custom user interfaces and interfaces created with Qt designer.<br />
<br />
== Design ==<br />
<br />
=== Recording ===<br />
<br />
Test case recording centers around the ''pqWidgetEventTranslator'' abstract interface class. Derivatives of this class are responsible for converting low-level Qt events ("mouse move", "button down", "button up", etc) into the high-level events (e.g: "button activated") that can be serialized and played back. pqWidgetEventTranslator derivatives may be particular to a specific widget type, such as ''pqComboBoxEventTranslator'', or may represent a class of related widgets, such as ''pqAbstractSliderEventTranslator'', which can translate events for any widget that derives from QAbstractSlider, including QDial, QScrollBar, and QSlider. pqWidgetEventTranslator derivatives implement the translateEvent() method, where they determine whether they can handle a Qt event, and if they can, convert it into a high-level event which consists of two strings: a ''command'', and the corresponding command ''arguments'' (which may be empty). The translator then emits the recordEvent() signal one-or-more times to pass the high-level event(s) to its container. It is intended that the test framework eventually include pqEventWidgetTranslator derivatives for all "stock" Qt widgets.<br />
<br />
A collection of pqWidgetEventTranslator objects is maintained at runtime by an instance of ''pqEventTranslator''. pqEventTranslator hooks itself into the Qt event loop as a top-level event filter, so it receives every Qt event that occurs at runtime for the entire application. pqEventTranslator passes the Qt event to each of its pqWidgetEventTranslator instances in-turn, until one of the instances signals that the event has been "consumed". When a pqWidgetEventTranslator emits a high-level event, the event is "caught" by the pqEventTranslator instance and combined with the serializable address of the widget to which the high-level event applies. The three strings (address, command, and arguments) of the complete high-level event are emitted from the pqEventTranslator as a Qt signal.<br />
<br />
The high-level event emitted from pqEventTranslator may be caught by any ''observer'' with the correct Qt slot. It is up to the observer(s) to serialize the high-level event for later playback. At this time the framework includes two observers, ''pqEventObserverStdout'' and ''pqEventObserverXML'', which serialize the high-level events to stdout and an XML file respectively. Developers can create their own observers to implement custom functionality, such as serializing events to a logfile, a Python script, etc.<br />
<br />
=== Playback ===<br />
<br />
Test case playback is basically a mirror-image of recording. An instance of ''pqEventPlayer'' is created, and high-level events are fed to it by a separate object. ''pqEventPlayerXML'' is the only current example, and is capable of reading the XML files generated by pqEventObserverXML.<br />
<br />
Derivatives of the ''pqWidgetEventPlayer'' abstract interface class are responsible for mapping high-level events back into low-level Qt events (or direct widget manipulation). Note that there is '''not''' a one-to-one correspondence between pqWidgetEventPlayer and pqWidgetEventTranslator derivatives - a single pqAbstractIntEventPlayer object is capable of handling events generated by both pqSpinBoxEventTranslator and pqAbstractSliderEventTranslator, because the two translators map dissimilar Qt events into a single, abstract "set_int" event.<br />
<br />
pqEventPlayer maintains a collection of pqWidgetEventPlayer objects, and as with pqEventTranslator, the set of pqWidgetEventPlayer objects can be instantiated by the developer or by pqEventTranslator, or both. Each high-level event is encoded as three strings(address, command, and arguments), which are fed to pqEventPlayer::playEvent(). pqEventPlayer decodes the address string and uses it to lookup the corresponding widget. The high-level event and widget are then passed to each pqWidgetEventPlayer in-turn, until one of them signals that the event has been handled.<br />
<br />
=== Extensions ===<br />
<br />
The test framework can be extended through the creation of custom components. To store high-level events to a custom format or device, the developer simply needs to create an observer class with a correctly-prototyped slot to receive events from pqEventTranslator. To play custom formats back, a developer simply calls the pqEventPlayer::playEvent() method repeatedly from whatever code suits their purpose, no other integration with the framework is necessary.<br />
<br />
Support for test case recording and playback of custom widgets is handled by creating custom derivatives of pqWidgetEventTranslator and pqWidgetEventPlayer, then adding instances of those custom derivatives to pqEventTranslator and pqEventPlayer, respectively. pqEventTranslator and pqEventPlayer also have methods that instantiate all of the "built in" translators and players that are part of the framework. Because translators and players are executed in-order until a given event has been handled, the developer can "override" builtin translators/players by adding their custom components first.<br />
<br />
== Implementation Challenges ==<br />
<br />
The main challenge in implementing the framework has been the mapping of high-level events to low-level Qt events for playback. In a nutshell, receiving useful events for recording is easy, because the API of a user interface toolkit such as Qt is fundamentally there to enable a client application to ''receive'' information about user interaction. Playback is more difficult because the synthesis of simulated user input is a highly specialized use case that is generally not supported or encouraged by the public API. This can lead to complex code, and generally requires an understanding of the internal implementation details of Qt widgets: on one hand, playing-back a button activation is simple, because the QAbstractButton::click() method is part of the API, while playing-back a menu activation is complex, because there is no comparable method for menu items. In the latter case, the implementation must synthesize enough low-level Qt events to simulate the corresponding user interaction.<br />
<br />
{{ParaView/Template/Footer}}</div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III_snapshots&diff=7118ParaView III snapshots2006-09-20T17:47:48Z<p>Tshead: /* June snapshot */</p>
<hr />
<div>== September snapshot - ParaView 2.9.3 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-intel.dmg Mac OS X, intel]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-ppc.dmg Mac OS X, power pc]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.zip Windows linefeed source]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the September snapshot of ParaView III. <br />
<br />
This snapshot includes binaries for Windows, Linux (32 and 64 bit) and Mac OS X. <br />
For those who have issues running the binaries, who cannot find the binary for their <br />
system or who want to see/modify the source code, source archives are also included.<br />
<br />
New features to look out for include:<br />
<br />
* Improved multi-view support:<br />
Try creating, destroying, maximizing, restoring and moving views. To move a<br />
view, click on it's toolbar and drag onto another view's toolbar.<br />
* Improved server connection and start dialog<br />
* Improved selection:<br />
Try turning on the element inspector before selecting,<br />
(View -> Element Inspector)<br />
* More toolbar buttons including those for manipulating camera. Better icons are<br />
coming soon<br />
* Separate camera undo/redo buttons for each view<br />
* Dialog for changing application and view settings (Edit -> Settings)<br />
* Capability to disconnect from server while saving an animation<br />
<br />
Also check out:<br />
<br />
* Custom filter dialog (tutorial coming)<br />
* Undo/redo<br />
* Custom reader/filter panels (try exodos reader, cut and clip)<br />
* Python scripting<br />
<br />
There is still very little documentation. Look at <br />
http://www.paraview.org/Wiki/ParaView_III to get more information on the <br />
new features. We will continue adding more documentation to this page as <br />
we progress.<br />
<br />
</pre><br />
<br />
== August snapshot - ParaView 2.9.2 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.zip Windows linefeed source]<br />
<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the August snapshot of ParaView. You can download it here: (see links above)<br />
<br />
...<br />
<br />
We regularly compile and run Windows, Linux and MacOS X.<br />
<br />
Please note that this is a development snapshot and may contain bugs. We have<br />
removed some of the limitations in this snapshot. It is now possible to access<br />
some of the features in development including multiple frames, all<br />
readers/sources/filters, python shell (requires compilation from source).<br />
<br />
There is still very little documentation. We will focus on that before the<br />
actual release.<br />
<br />
-Berk<br />
</pre><br />
<br />
== July snapshot - ParaView 2.9.1 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.1-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Linux binary (32 bit)]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the june snapshot of ParaView 2.9 (to be 3.0) on the web. <br />
There are binaries for linux (x86) and windows. Make sure you download 2.9.1.<br />
2.9.0 is the snapshot from May. I also uploaded an exodus file<br />
(disk_out_ref.exo). It is good file to play with to see some of the new features.<br />
<br />
Some new features to look for (in no particular order):<br />
<br />
* Support for more file formats (exodus reader is still the one that is tested<br />
and customized best)<br />
* Statistics view<br />
* Two undo/redo stacks: 1. pipeline operations (ctrl+z, ctrl+r) 2. view<br />
operation (ctrl+b, ctrl+f)<br />
* Visibility control on the pipeline inspector<br />
* Selection (still at alpha, use toolbar buttons or 's' key to switch between<br />
interaction & selection)<br />
* Support for more sources<br />
* Support for contour and streamlines filters<br />
* Support for saving & loading state<br />
* Saving screenshot<br />
* Saving animation. Very alpha. It only support creating animations from readers<br />
that support time (File->Save Animation)<br />
* Bug fixes<br />
<br />
We are working on:<br />
<br />
* Readers/filters<br />
* Custom filters (being able to create custom filters by selection part of a<br />
pipeline, saving, loading and instantiating them)<br />
* Full featured animation<br />
* Colormap editor<br />
* Application/3D view settings<br />
* Python interface<br />
* Selection<br />
* Server connection interface<br />
<br />
Longer term:<br />
<br />
* Support for multiple views<br />
* Client side plotting using Qt widgets (2D plots, histogram)<br />
* Multiple server connection<br />
* Multiple client connection<br />
<br />
Some of these features are already in alpha stage and are enabled in the CVS<br />
development tree. I disabled them to make binaries. Use the snapshots and CVS at<br />
your own risk. I would not recommend using 2.9 for production use. Bug reports<br />
are obviously welcome.<br />
</pre><br />
<br />
== June snapshot - ParaView 2.9.0 (alpha) ==<br />
<br />
=== Download Link ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Windows binary]<br />
<br />
=== Announcement ===<br />
<pre><br />
Kitware, Sandia National Labs and Elemental Technologies have been working on<br />
ParaView 3.0 for a few months. ParaView 3.0 will have a myriad of new features<br />
including a brand new interface. This interface is based on the Qt library<br />
(http://www.trolltech.com/products/qt) and is designed to be easy to use and<br />
elegant. Paraview 3.0 will also have a greatly expanded emphasis on quantitative<br />
analysis, with lots of plotting, graphing, and linked views. We have our first<br />
development snapshot.<br />
<br />
Currently, we are working on a separate CVS repository so the source code for<br />
the Qt interface is not yet available. We will open this CVS repository soon and<br />
we will merge the two repositories sometime in the future, most probably before<br />
the release of ParaView 2.6 in Q4 of 2006.<br />
<br />
Please keep in mind that this is not even a beta but more a development<br />
snapshot. We expect the development will take several more months. Comments and<br />
feedback are as usual welcome.<br />
<br />
Regards,<br />
ParaView Team<br />
</pre></div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III_snapshots&diff=7117ParaView III snapshots2006-09-20T17:47:28Z<p>Tshead: /* July snapshot */</p>
<hr />
<div>== September snapshot - ParaView 2.9.3 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-intel.dmg Mac OS X, intel]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-ppc.dmg Mac OS X, power pc]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.zip Windows linefeed source]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the September snapshot of ParaView III. <br />
<br />
This snapshot includes binaries for Windows, Linux (32 and 64 bit) and Mac OS X. <br />
For those who have issues running the binaries, who cannot find the binary for their <br />
system or who want to see/modify the source code, source archives are also included.<br />
<br />
New features to look out for include:<br />
<br />
* Improved multi-view support:<br />
Try creating, destroying, maximizing, restoring and moving views. To move a<br />
view, click on it's toolbar and drag onto another view's toolbar.<br />
* Improved server connection and start dialog<br />
* Improved selection:<br />
Try turning on the element inspector before selecting,<br />
(View -> Element Inspector)<br />
* More toolbar buttons including those for manipulating camera. Better icons are<br />
coming soon<br />
* Separate camera undo/redo buttons for each view<br />
* Dialog for changing application and view settings (Edit -> Settings)<br />
* Capability to disconnect from server while saving an animation<br />
<br />
Also check out:<br />
<br />
* Custom filter dialog (tutorial coming)<br />
* Undo/redo<br />
* Custom reader/filter panels (try exodos reader, cut and clip)<br />
* Python scripting<br />
<br />
There is still very little documentation. Look at <br />
http://www.paraview.org/Wiki/ParaView_III to get more information on the <br />
new features. We will continue adding more documentation to this page as <br />
we progress.<br />
<br />
</pre><br />
<br />
== August snapshot - ParaView 2.9.2 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.zip Windows linefeed source]<br />
<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the August snapshot of ParaView. You can download it here: (see links above)<br />
<br />
...<br />
<br />
We regularly compile and run Windows, Linux and MacOS X.<br />
<br />
Please note that this is a development snapshot and may contain bugs. We have<br />
removed some of the limitations in this snapshot. It is now possible to access<br />
some of the features in development including multiple frames, all<br />
readers/sources/filters, python shell (requires compilation from source).<br />
<br />
There is still very little documentation. We will focus on that before the<br />
actual release.<br />
<br />
-Berk<br />
</pre><br />
<br />
== July snapshot - ParaView 2.9.1 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.1-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Linux binary (32 bit)]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the june snapshot of ParaView 2.9 (to be 3.0) on the web. <br />
There are binaries for linux (x86) and windows. Make sure you download 2.9.1.<br />
2.9.0 is the snapshot from May. I also uploaded an exodus file<br />
(disk_out_ref.exo). It is good file to play with to see some of the new features.<br />
<br />
Some new features to look for (in no particular order):<br />
<br />
* Support for more file formats (exodus reader is still the one that is tested<br />
and customized best)<br />
* Statistics view<br />
* Two undo/redo stacks: 1. pipeline operations (ctrl+z, ctrl+r) 2. view<br />
operation (ctrl+b, ctrl+f)<br />
* Visibility control on the pipeline inspector<br />
* Selection (still at alpha, use toolbar buttons or 's' key to switch between<br />
interaction & selection)<br />
* Support for more sources<br />
* Support for contour and streamlines filters<br />
* Support for saving & loading state<br />
* Saving screenshot<br />
* Saving animation. Very alpha. It only support creating animations from readers<br />
that support time (File->Save Animation)<br />
* Bug fixes<br />
<br />
We are working on:<br />
<br />
* Readers/filters<br />
* Custom filters (being able to create custom filters by selection part of a<br />
pipeline, saving, loading and instantiating them)<br />
* Full featured animation<br />
* Colormap editor<br />
* Application/3D view settings<br />
* Python interface<br />
* Selection<br />
* Server connection interface<br />
<br />
Longer term:<br />
<br />
* Support for multiple views<br />
* Client side plotting using Qt widgets (2D plots, histogram)<br />
* Multiple server connection<br />
* Multiple client connection<br />
<br />
Some of these features are already in alpha stage and are enabled in the CVS<br />
development tree. I disabled them to make binaries. Use the snapshots and CVS at<br />
your own risk. I would not recommend using 2.9 for production use. Bug reports<br />
are obviously welcome.<br />
</pre><br />
<br />
== June snapshot ==<br />
<br />
=== Download Link ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Windows binary]<br />
<br />
=== Announcement ===<br />
<pre><br />
Kitware, Sandia National Labs and Elemental Technologies have been working on<br />
ParaView 3.0 for a few months. ParaView 3.0 will have a myriad of new features<br />
including a brand new interface. This interface is based on the Qt library<br />
(http://www.trolltech.com/products/qt) and is designed to be easy to use and<br />
elegant. Paraview 3.0 will also have a greatly expanded emphasis on quantitative<br />
analysis, with lots of plotting, graphing, and linked views. We have our first<br />
development snapshot.<br />
<br />
Currently, we are working on a separate CVS repository so the source code for<br />
the Qt interface is not yet available. We will open this CVS repository soon and<br />
we will merge the two repositories sometime in the future, most probably before<br />
the release of ParaView 2.6 in Q4 of 2006.<br />
<br />
Please keep in mind that this is not even a beta but more a development<br />
snapshot. We expect the development will take several more months. Comments and<br />
feedback are as usual welcome.<br />
<br />
Regards,<br />
ParaView Team<br />
</pre></div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III_snapshots&diff=7116ParaView III snapshots2006-09-20T17:47:06Z<p>Tshead: /* August snapshot */</p>
<hr />
<div>== September snapshot - ParaView 2.9.3 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-intel.dmg Mac OS X, intel]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-ppc.dmg Mac OS X, power pc]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.zip Windows linefeed source]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the September snapshot of ParaView III. <br />
<br />
This snapshot includes binaries for Windows, Linux (32 and 64 bit) and Mac OS X. <br />
For those who have issues running the binaries, who cannot find the binary for their <br />
system or who want to see/modify the source code, source archives are also included.<br />
<br />
New features to look out for include:<br />
<br />
* Improved multi-view support:<br />
Try creating, destroying, maximizing, restoring and moving views. To move a<br />
view, click on it's toolbar and drag onto another view's toolbar.<br />
* Improved server connection and start dialog<br />
* Improved selection:<br />
Try turning on the element inspector before selecting,<br />
(View -> Element Inspector)<br />
* More toolbar buttons including those for manipulating camera. Better icons are<br />
coming soon<br />
* Separate camera undo/redo buttons for each view<br />
* Dialog for changing application and view settings (Edit -> Settings)<br />
* Capability to disconnect from server while saving an animation<br />
<br />
Also check out:<br />
<br />
* Custom filter dialog (tutorial coming)<br />
* Undo/redo<br />
* Custom reader/filter panels (try exodos reader, cut and clip)<br />
* Python scripting<br />
<br />
There is still very little documentation. Look at <br />
http://www.paraview.org/Wiki/ParaView_III to get more information on the <br />
new features. We will continue adding more documentation to this page as <br />
we progress.<br />
<br />
</pre><br />
<br />
== August snapshot - ParaView 2.9.2 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.zip Windows linefeed source]<br />
<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the August snapshot of ParaView. You can download it here: (see links above)<br />
<br />
...<br />
<br />
We regularly compile and run Windows, Linux and MacOS X.<br />
<br />
Please note that this is a development snapshot and may contain bugs. We have<br />
removed some of the limitations in this snapshot. It is now possible to access<br />
some of the features in development including multiple frames, all<br />
readers/sources/filters, python shell (requires compilation from source).<br />
<br />
There is still very little documentation. We will focus on that before the<br />
actual release.<br />
<br />
-Berk<br />
</pre><br />
<br />
== July snapshot ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.1-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Linux binary (32 bit)]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the june snapshot of ParaView 2.9 (to be 3.0) on the web. <br />
There are binaries for linux (x86) and windows. Make sure you download 2.9.1.<br />
2.9.0 is the snapshot from May. I also uploaded an exodus file<br />
(disk_out_ref.exo). It is good file to play with to see some of the new features.<br />
<br />
Some new features to look for (in no particular order):<br />
<br />
* Support for more file formats (exodus reader is still the one that is tested<br />
and customized best)<br />
* Statistics view<br />
* Two undo/redo stacks: 1. pipeline operations (ctrl+z, ctrl+r) 2. view<br />
operation (ctrl+b, ctrl+f)<br />
* Visibility control on the pipeline inspector<br />
* Selection (still at alpha, use toolbar buttons or 's' key to switch between<br />
interaction & selection)<br />
* Support for more sources<br />
* Support for contour and streamlines filters<br />
* Support for saving & loading state<br />
* Saving screenshot<br />
* Saving animation. Very alpha. It only support creating animations from readers<br />
that support time (File->Save Animation)<br />
* Bug fixes<br />
<br />
We are working on:<br />
<br />
* Readers/filters<br />
* Custom filters (being able to create custom filters by selection part of a<br />
pipeline, saving, loading and instantiating them)<br />
* Full featured animation<br />
* Colormap editor<br />
* Application/3D view settings<br />
* Python interface<br />
* Selection<br />
* Server connection interface<br />
<br />
Longer term:<br />
<br />
* Support for multiple views<br />
* Client side plotting using Qt widgets (2D plots, histogram)<br />
* Multiple server connection<br />
* Multiple client connection<br />
<br />
Some of these features are already in alpha stage and are enabled in the CVS<br />
development tree. I disabled them to make binaries. Use the snapshots and CVS at<br />
your own risk. I would not recommend using 2.9 for production use. Bug reports<br />
are obviously welcome.<br />
</pre><br />
<br />
== June snapshot ==<br />
<br />
=== Download Link ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Windows binary]<br />
<br />
=== Announcement ===<br />
<pre><br />
Kitware, Sandia National Labs and Elemental Technologies have been working on<br />
ParaView 3.0 for a few months. ParaView 3.0 will have a myriad of new features<br />
including a brand new interface. This interface is based on the Qt library<br />
(http://www.trolltech.com/products/qt) and is designed to be easy to use and<br />
elegant. Paraview 3.0 will also have a greatly expanded emphasis on quantitative<br />
analysis, with lots of plotting, graphing, and linked views. We have our first<br />
development snapshot.<br />
<br />
Currently, we are working on a separate CVS repository so the source code for<br />
the Qt interface is not yet available. We will open this CVS repository soon and<br />
we will merge the two repositories sometime in the future, most probably before<br />
the release of ParaView 2.6 in Q4 of 2006.<br />
<br />
Please keep in mind that this is not even a beta but more a development<br />
snapshot. We expect the development will take several more months. Comments and<br />
feedback are as usual welcome.<br />
<br />
Regards,<br />
ParaView Team<br />
</pre></div>Tsheadhttps://public.kitware.com/Wiki/index.php?title=ParaView_III_snapshots&diff=7115ParaView III snapshots2006-09-20T17:46:15Z<p>Tshead: </p>
<hr />
<div>== September snapshot - ParaView 2.9.3 (alpha) ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-intel.dmg Mac OS X, intel]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.3-darwin-ppc.dmg Mac OS X, power pc]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-September.zip Windows linefeed source]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the September snapshot of ParaView III. <br />
<br />
This snapshot includes binaries for Windows, Linux (32 and 64 bit) and Mac OS X. <br />
For those who have issues running the binaries, who cannot find the binary for their <br />
system or who want to see/modify the source code, source archives are also included.<br />
<br />
New features to look out for include:<br />
<br />
* Improved multi-view support:<br />
Try creating, destroying, maximizing, restoring and moving views. To move a<br />
view, click on it's toolbar and drag onto another view's toolbar.<br />
* Improved server connection and start dialog<br />
* Improved selection:<br />
Try turning on the element inspector before selecting,<br />
(View -> Element Inspector)<br />
* More toolbar buttons including those for manipulating camera. Better icons are<br />
coming soon<br />
* Separate camera undo/redo buttons for each view<br />
* Dialog for changing application and view settings (Edit -> Settings)<br />
* Capability to disconnect from server while saving an animation<br />
<br />
Also check out:<br />
<br />
* Custom filter dialog (tutorial coming)<br />
* Undo/redo<br />
* Custom reader/filter panels (try exodos reader, cut and clip)<br />
* Python scripting<br />
<br />
There is still very little documentation. Look at <br />
http://www.paraview.org/Wiki/ParaView_III to get more information on the <br />
new features. We will continue adding more documentation to this page as <br />
we progress.<br />
<br />
</pre><br />
<br />
== August snapshot ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86.tar.gz Linux binary (32 bit)]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.2-Linux-x86_em64.tar.gz Linux binary (64 bit, EMT)]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.tgz Unix linefeed source]<br />
* [http://paraview.org/files/v2.9/ParaView2-9-August.zip Windows linefeed source]<br />
<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the August snapshot of ParaView. You can download it here: (see links above)<br />
<br />
...<br />
<br />
We regularly compile and run Windows, Linux and MacOS X.<br />
<br />
Please note that this is a development snapshot and may contain bugs. We have<br />
removed some of the limitations in this snapshot. It is now possible to access<br />
some of the features in development including multiple frames, all<br />
readers/sources/filters, python shell (requires compilation from source).<br />
<br />
There is still very little documentation. We will focus on that before the<br />
actual release.<br />
<br />
-Berk<br />
</pre><br />
<br />
== July snapshot ==<br />
<br />
=== Download Links ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.1-win32-x86.exe Windows binary]<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Linux binary (32 bit)]<br />
<br />
=== Announcement ===<br />
<br />
<pre><br />
Hi Folks,<br />
<br />
I posted the june snapshot of ParaView 2.9 (to be 3.0) on the web. <br />
There are binaries for linux (x86) and windows. Make sure you download 2.9.1.<br />
2.9.0 is the snapshot from May. I also uploaded an exodus file<br />
(disk_out_ref.exo). It is good file to play with to see some of the new features.<br />
<br />
Some new features to look for (in no particular order):<br />
<br />
* Support for more file formats (exodus reader is still the one that is tested<br />
and customized best)<br />
* Statistics view<br />
* Two undo/redo stacks: 1. pipeline operations (ctrl+z, ctrl+r) 2. view<br />
operation (ctrl+b, ctrl+f)<br />
* Visibility control on the pipeline inspector<br />
* Selection (still at alpha, use toolbar buttons or 's' key to switch between<br />
interaction & selection)<br />
* Support for more sources<br />
* Support for contour and streamlines filters<br />
* Support for saving & loading state<br />
* Saving screenshot<br />
* Saving animation. Very alpha. It only support creating animations from readers<br />
that support time (File->Save Animation)<br />
* Bug fixes<br />
<br />
We are working on:<br />
<br />
* Readers/filters<br />
* Custom filters (being able to create custom filters by selection part of a<br />
pipeline, saving, loading and instantiating them)<br />
* Full featured animation<br />
* Colormap editor<br />
* Application/3D view settings<br />
* Python interface<br />
* Selection<br />
* Server connection interface<br />
<br />
Longer term:<br />
<br />
* Support for multiple views<br />
* Client side plotting using Qt widgets (2D plots, histogram)<br />
* Multiple server connection<br />
* Multiple client connection<br />
<br />
Some of these features are already in alpha stage and are enabled in the CVS<br />
development tree. I disabled them to make binaries. Use the snapshots and CVS at<br />
your own risk. I would not recommend using 2.9 for production use. Bug reports<br />
are obviously welcome.<br />
</pre><br />
<br />
== June snapshot ==<br />
<br />
=== Download Link ===<br />
* [http://paraview.org/files/v2.9/paraview-2.9.0-win32-x86.exe Windows binary]<br />
<br />
=== Announcement ===<br />
<pre><br />
Kitware, Sandia National Labs and Elemental Technologies have been working on<br />
ParaView 3.0 for a few months. ParaView 3.0 will have a myriad of new features<br />
including a brand new interface. This interface is based on the Qt library<br />
(http://www.trolltech.com/products/qt) and is designed to be easy to use and<br />
elegant. Paraview 3.0 will also have a greatly expanded emphasis on quantitative<br />
analysis, with lots of plotting, graphing, and linked views. We have our first<br />
development snapshot.<br />
<br />
Currently, we are working on a separate CVS repository so the source code for<br />
the Qt interface is not yet available. We will open this CVS repository soon and<br />
we will merge the two repositories sometime in the future, most probably before<br />
the release of ParaView 2.6 in Q4 of 2006.<br />
<br />
Please keep in mind that this is not even a beta but more a development<br />
snapshot. We expect the development will take several more months. Comments and<br />
feedback are as usual welcome.<br />
<br />
Regards,<br />
ParaView Team<br />
</pre></div>Tshead