[CMake] CPack

[Taras Shypytiak]

Hi,all
I apologize in advance  if my question is wrong.
I have the next problem:
I have to package a project which includes many subprojects. When 
reading CPack documentation I've found how to install files,targets and 
etc,but I still have no idea how to include whole subproject which 
consists of large amount of sub directories.

I supposed to use smth. like this:
SET(CPACK_INSTALL_CMAKE_PROJECTS 
"${CMAKE_CURRENT_BINARY_DIR}/../../IXCWeb/;IXCWeb;ALL;/")

but got an error:
Run command: /usr/local/bin/gmake "preinstall"
# Directory: /home/alm/IXC/SS/build/../../IXCWeb/
# Output:
gmake: *** No rule to make target `preinstall'.  Stop.

Could somebody advise me how to deal with this?
Thank you in adwance
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack

[Alexander.Camek]

Hello List,

I want to use the CPACK generator, but the tutorial 
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack is not quite good.
Perhaps somebody knows a better site.

When I run make with make package, then I get following error:
CPack Error: Cannot find a sutable ZIP program <- an I is missing in suitable ;)
CPack Error: Cannot initialize the generator

In my cmake file, I use following commands:
IF(WIN32)
  SET(CPACK_GENERATOR ZIP)
  SET(CPACK_SOURCE_GENERATOR ZIP)
ELSE(WIN32)
  SET(CPACK_GENERATOR TGZ)
  SET(CPACK_SOURCE_GENERATOR TGZ)
ENDIF(WIN32)
INCLUDE(CPack)

But on the other side I do have 7zip installed. 7zip is working because I 
unpack some files during my build process.
So does the current release 2.4.7 support 7zip?
If not so then you should add this info to 
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators.

Thanks for your help.

Greetings

Alexander



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack 101

[KC Jones]

Feeling really uneasy about putting this out there, but here goes...

I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and 
Linux (Ubuntu 10.04).
The app depends on some libraries (Qt4.6 (no plugins) and a customized build of 
Poco).
I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + Poco 
lib packaging)
On Linux, I want a Debian package to install the Poco libs at a minimum along 
with my executable.
Equivalent Windows installers will be needed someday.

I've reviewed the docs at http://www.cmake.org/cmake/help/cmake-2-8-docs.html
I've reviewed bits and pieces on the wiki:
http://www.cmake.org/Wiki/BundleUtilitiesExample
http://www.cmake.org/Wiki/CMake#CPack

And I just don't seem to get it. I know this is very possible.  I know this is 
my own problem, first and foremost.  So I'm exposing myself to potential 
criticism here since RTFM and "get a clue" are probably the biggest part of 
fixing my problem.  Im not really asking for specific help on my code - I might 
ask for that later.  For now I just want to vent, hopefully in a constructive 
way.

I just don't think that CPack documentation and examples as they currently are 
published are sufficient or effective.

A few suggestions:
More CPack example and tutorials would be very helpful.  I see from archive 
searches that I'm not the first to suggest this.  The Qt example is great, but 
the plugin support is overkill for most, and obfuscates much of the rest of the 
example.
A step-wise tutorial format that starts with a working build, adds install 
target support, then adds CPack code would help my addled brain.  Presenting 
newbies like me with a fully baked end result is helpful, but somewhat hard to 
digest.
Separating the docs into different namespaces (Cmake, CPack, CTest...) might be 
more effective.  I struggled a long while before finding the install command 
docs (which I continue to struggle with). The atomic layout of the docs 
obscures the module-level relationships.
A glossary, please.  For instance "bundle" comes out of OS X, but now has some 
CMake-specific meaning for Linux and Win that I know is very important to me, 
but fully incomprehensible in my reading so far.  Oh, and what are bundle keys?
More meta docs please.  Somewhere in my stumbling I found a decent diagram 
about how the ExternalProject module works.  I think it was on the wiki, but I 
can't find it now.  I would die for something similar that shows what install 
does and how it integrates with CPack.  Same goes for BudleUtilities and other 
modules I've yet to discover.

One final comment, cmake is elegant in the extreme.  I can see from some of the 
wiki pages about how install is a merge that canonically folds multiple 
precursors into one uber-powerful, uber-flexible silver bullet.  Impressive I'm 
sure.  But harder to grok.  I'm not suggesting that this is a wrong choice.  
But it is a barrier to learning.  Where there is this kind of folding of 
advanced features into basic operations, some care is needed to ensure the docs 
convey the basics clearly.

WRT Cpack, what I find is that by merging it into CMake, the CPack code is 
declared one step away from where it is applied.  The need for careful quoting 
in install(CODE ) blocks is a case in point.  I'm sure this folding into a 
canonical, unified single CMakeLists.txt source is a good thing.  But right now 
I feel like I'm learning Lisp again.  Kind of mind blowing.  Wishing I had some 
better training wheels to break this down for me...

Thanks for your indulgence.  I hope this does not offend those who've put so 
much into this great tool.

KC Jones
kc.jo...@skype.net
SkypeId: bernalkc

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack error

[Macumber, Daniel]

Hello, I am using CPack with 'include(InstallRequiredSystemLibraries)' under 
Windows 7, VS 2008, and NSIS.  When I try to build package I get the following 
error and the package fails to build:



1>-- Build started: Project: PACKAGE, Configuration: Release Win32 --

1>

1>Performing Post-Build Event...

1>CPack: Create package using NSIS

1>CPack: Install projects

1>CPack: - Install project: OpenStudio

1>warning: target 'GPSVC.dll' is not absolute...

1>warning: target 'GPSVC.dll' does not exist...

1>Error copying file "GPSVC.dll" to 
"C:/working/openstudioTrunk/build/_CPack_Packages/win32/NSIS/OpenStudio-0.3.7.Unknown-Windows/bin/GPSVC.dll".

1>warning: target 'GPSVC.dll' is not absolute...

1>warning: target 'GPSVC.dll' does not exist...

1>CMake Error at C:/Program Files (x86)/CMake 
2.8/share/cmake-2.8/Modules/BundleUtilities.cmake:691 (message):

1> error: verify_app failed

1>Call Stack (most recent call first):

1> C:/Program Files (x86)/CMake 
2.8/share/cmake-2.8/Modules/BundleUtilities.cmake:551 (verify_app)

1> C:/working/openstudioTrunk/build/cmake_install.cmake:51 (fixup_bundle)

1>CPack Error: Error when generating package: OpenStudio

1>Project : error PRJ0019: A tool returned an error code from "Performing 
Post-Build Event..."

1>Build log was saved at 
"file://c:\working\openstudioTrunk\build\PACKAGE.dir\Release\BuildLog.htm"

1>PACKAGE - 1 error(s), 0 warning(s)

== Build: 0 succeeded, 1 failed, 84 up-to-date, 0 skipped ==



I am building a 32 bit application but am on a 64 bit machine and I have read 
several posts about GPSVC.dll being a problem on Windows 7 when only the 64 bit 
version is available.  I'm not sure that I actually need this dll in the first 
place either.  Does anyone know how to get around this?

Thanks a lot,
Dan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack & WiX

[Tim St. Clair]

I was just wondering if anyone has created a WiX cpack-generator yet,
the wiki says "no", but the wiki is stale and I'm rather surprised
that no one has done it.

-- 
Cheers,
Timothy St. Clair
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack components

[Clinton Stimpson]

I have a project with install commands like so:

INSTALL(TARGETS foo
RUNTIME DESTINATION bin COMPONENT Runtime
LIBRARY DESTINATION bin COMPONENT Runtime
ARCHIVE DESTINATION bin COMPONENT Development)
INSTALL(FILES ${foo_HDRS}
DESTINATION include COMPONENT Development)

And I want to create a .tgz or .zip file with a subset of the available 
components (in my case, Runtime and Help).  I've set CPACK_COMPONENTS_ALL to a 
list of components I want before the include(CPack), but it is being ignored.

With generators that support components, I can list a subset of components to 
install.  But it seems with non-component based cpack generators I can't list 
a subset of components.

Any way to get what I want?  I looked at the CPACK_INSTALL_CMAKE_PROJECTS 
variable, but its a list of 4 items, and I don't see how I can fit in a list in 
the 3rd position of that list.

Thanks,
Clint

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack -C

[Bo Thorsen]

Hi good people,

When I give an argument to -C, can this be used in the INSTALL commands?

I have a generated file in /libmysqld.exp that I need in the 
installer, and I'm having a lot of problems figuring out how to do this 
properly.


I have this line in a subdir CMakeLists.txt:

INSTALL(FILES 
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_BUILD_TYPE}/libmysqld.exp 
DESTINATION Embedded/DLL COMPONENT embedded)


In the top level CMakeLists.txt, it says this:

IF(NOT CMAKE_BUILD_TYPE)
SET(CMAKE_BUILD_TYPE "RelWithDebInfo")
ENDIF()

When I run cpack the ${CMAKE_BUILD_TYPE} is expanded to nothing.

Is there a variable that contains the contents of the -C argument?

Bo Thorsen.
Monty Program AB.

--

MariaDB: MySQL replacement
Community developed. Feature enhanced. Backward compatible.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack integration

[Dennis Schridde]

Hello!

I just started experimenting with CPack. According to the docs and
code it is to be used like this:
> set(CPACK_... ...)
>
include(CPack)

This, however, does not allow making use of the defaults
present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
I had to
copy the default value of that variable out of CPack.cmake into my own
CMakeLists.txt, which does not seem very clean.

Can you add a way of
configuring CPack that allows appending or modifying default values?
What
comes to my mind is a semantic like this:
> include(CPack)
> set(CPACK_...
"${CPACK_...} ...")
> cpack_config()

Kind regards,
Dennis


signature.asc
Description: This is a digitally signed message part.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack question.

[Akshay]

Hello All,

I have recently ported my project software tree to CMake and I am pretty
happy about it. There is a last step which is proving quite elusive to me.
The targets that are built in the software tree are TGZ'd for final
distribution, however, CPack if run from the CMakeLists.txt file will pickup
only those targets which are installed by INSTALL command. I can't change
the directory structure for historical reasons. If I use INSTALL from the
individual directories' CMakeLists.txt, CPack from the main CMakeLists.txt
is not finding anything and generates an empty TGZ.

src
|- a
|- b
|- c
|- dt
|- proj
   |- CMakeLists.txt (main)
   |- build
|- e
   |- x
   |- y
   |- z

Akshay
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack problem

[ycollette . nospam]

Hello,

I've built an installer using cmake / cpack / nsis. I work under windpws XP 64 
bits.
I first built a "monolithic" installer and everything is fine. My installer 
have several components.
Now, I build a "network" installation. So, I added:

  cpack_configure_downloads(ftp://ftp.myftpsite.fr/New
ALL)

I have installed the nsis plugin ZipDLL in the right place.
The installer builds nicely. I uploaded all the zipped component on my ftp site 
and now, if I execute the installer, all the selected components are correctly 
installed but:
- all the files are hidden ...
- another problem, two components have a file in common. ZipDLL doesn't like 
this and an error message is displayed. I needed to add another component to 
store the common files, and add a dependency in the cmakelists.txt file.

Does somebody had the same problem (all installed files are hidden) ?

Best regards,

YC

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack issues

[Andrea Crotti]

I'm trying to finally create an installer for my project, with CPack and 
NSIS.


The project is really really simple, I just need to copy over a 
directory somewhere.

And I did something like:

get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)

install(
  DIRECTORY ${EGG_BUILD_DIRECTORY}
  DESTINATION ${userprofile}/${PROJECT_NAME}
  )


The first line is because CPack was exploding using the USERPROFILE, because
it was getting non quoted backslash.

So is it the way to handle windows path variables?

The packing, however, doesn't work and I get something like (from the 
NSIS generated log file):


!insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
Section: "-Core installation"
SetOutPath: "$INSTDIR"
File: Returning to: "H:/long_path/_CPack_Packages/win32/NSIS/Minimum 
Drag-0.1.1-win32"
File: "H:/long_path/_CPack_Packages/win32/NSIS/Minimum 
Drag-0.1.1-win32\*.*" -> no files found.

Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
   /oname=outfile one_file_only)
Error in script 
"H:/git_projs/Minimum_Drag/airbus.application.minimum_drag/_CPack_Packages/win32/NSIS/project.nsi" 
on line 640 -- aborting creation process


These are the variables that I defined
set(CPACK_NSIS_INSTALLED_ICON_NAME "${PROJECT_NAME}")
set(CPACK_PACKAGE_ICON "Company")
set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})

set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/COPYRIGHT.txt")
set(CPACK_PACKAGE_VERSION_MAJOR 0)
set(CPACK_PACKAGE_VERSION_MINOR 1)
set(CPACK_CREATE_DESKTOP_LINKS "${PROJECT_NAME}")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "${PROJECT_NAME}") # add the version 
numbers

set(CPACK_PACKAGE_DESCRIPTION "Package ${PROJECT_NAME}")


is there anything missing?
Any idea what that could be?
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack components

[Mathieu Malaterre]

Just saw the recent commit in cmake, cpack components looks awesome !

http://public.kitware.com/Wiki/CMake:Component_Install_With_CPack

Kudos !

-- 
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack preinstall

[KSpam]

Is there a way to disable running the preinstall target while running CPack?

Unfortunately, the preinstall target takes a significant amount of time (very 
large project), and it gets run for each component when selecting specific 
components for packaging.  In the case of my very large project containing 
several dozen potential components, a single CPack script might bundle a 
dozen components into an installer.  This would require running preinstall a 
dozen times.  The overhead is simply unbearable.

Thanks,
Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack, rebrand

[schoappied]

Hi,


I want to rebrand a package. It would be nice if I could do that without 
changing a lot of code, so I was wondering if I rename the *.exe binary 
and point the installer and menu item on Windows to that renamed binary 
using cpack?


Any suggestions, tips?

Thanks in advance,

\d
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack help

[David Blado]

Hi All,

 

I was hoping that someone here could help
me out w/ cpack.  I’ve copied sample CMakeLists cpack section with
no success.  Every time I issue make package the package comes out empty.

 

I do have some INSTALL commands defined
and they work perfectly fine when I do ‘make install’

 

I see the following:

 

Run CPack packaging tool...

CPack: Create package using TGZ

CPack: Install projects

CPack: - Run preinstall target for: test

CPack: - Install project: test

CPack: Compress package

CPack: Finalize package

CPack: Package
/home/dblado/dds4.1.3/Common2/TMClib/src/test-0.1.1-Linux.tar.gz generated.

 

But if I do tar ztvf on the file,
it’s empty.

 

Anyone have any hints or tips? 
I’ve tried w/ a basic ‘INCLUDE(CPack)’ as well as specifying
the options @ http://www.cmake.org/Wiki/CMake:Packaging_With_CPack

 

Any help would be greatly appreciated.

 

Cheers,
David

 






___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack question

[Alexander Neundorf]

Hi,

today I tried cpack for the first time, it just worked :-)

One question:
in the tar.gz and .sh files the install always ends up in 
projectname-versionnumber/.
I tried setting CPACK_PACKAGE_INSTALL_DIRECTORY to /usr/local/, but the tgz 
didn't seem to honor this flag.
Bug or feature ?
(cmake 2.4.6)

Bye
Alex

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack targets

[Robert Bielik]

Hi all,

Just looking into using CPack for generating our installation scripts. On 
Windows I can see only NSIS, are there any
efforts towards generating an XML for WiX (so that a .msi file can be created)?

Thanks
/Robert

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack again..

[Robert Bielik]

Is CPack anything that is "alive"? The lack of responses makes me feel "not"... 
(?)

/R

 Ursprungligt meddelande ----
Ämne: [CMake] CPack targets
Datum: Wed, 22 Aug 2007 15:35:56 +0200
Från: Robert Bielik <[EMAIL PROTECTED]>
Organisation: Xponaut
Till: cmake@cmake.org

Hi all,

Just looking into using CPack for generating our installation scripts. On 
Windows I can see only NSIS, are there any
efforts towards generating an XML for WiX (so that a .msi file can be created)?

Thanks
/Robert

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack

[Eric Noulard]

2007/9/17, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hello List,
>
> I want to use the CPACK generator, but the tutorial 
> http://www.cmake.org/Wiki/CMake:Packaging_With_CPack is not quite good.
> Perhaps somebody knows a better site.
>
> When I run make with make package, then I get following error:
> CPack Error: Cannot find a sutable ZIP program <- an I is missing in suitable 
> ;)
> CPack Error: Cannot initialize the generator
>
> In my cmake file, I use following commands:
> IF(WIN32)
>   SET(CPACK_GENERATOR ZIP)
>   SET(CPACK_SOURCE_GENERATOR ZIP)
> ELSE(WIN32)
>   SET(CPACK_GENERATOR TGZ)
>   SET(CPACK_SOURCE_GENERATOR TGZ)
> ENDIF(WIN32)
> INCLUDE(CPack)
>
> But on the other side I do have 7zip installed. 7zip is working because I 
> unpack some files during my build process.
> So does the current release 2.4.7 support 7zip?

I think this is a know (already reported) bug which has been fixed
in the CVS version of CMake:
see
http://public.kitware.com/pipermail/cmake/2007-June/014735.html

However, I did not find a corresponding bug entry in the tracker.

> If not so then you should add this info to
> http://www.cmake.org/Wiki/CMake:CPackPackageGenerators.

This is a Wiki so you may (after checking like you did)
modifiy the page yourself.

Since you are on windows you may want to try
a nightly build of CMake CVS version:

http://www.cmake.org/files/vCVS/

It should properly handle 7zip (I think I already used it).
(However THIS IS NOT a CMake VERSION just a development snapshot).


-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack

[Eric Noulard]

2007/9/17, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hi Eric,
>
> Thanks for your reply.
>
> > Since you are on windows you may want to try a nightly build
> > of CMake CVS version:
> >
> > http://www.cmake.org/files/vCVS/
> >
> > It should properly handle 7zip (I think I already used it).
> > (However THIS IS NOT a CMake VERSION just a development snapshot).
>
> So this is planed to be in the next released version of Cmake?

I cannot answer this.
I am a simple CMake "watcher/contributor"

CMake maintainer may answer to this question.

PS: don't forget to CC the list.
-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack

[Hendrik Sattler]

Zitat von [EMAIL PROTECTED]:
I want to use the CPACK generator, but the tutorial   
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack is not quite   
good.

Perhaps somebody knows a better site.

When I run make with make package, then I get following error:
CPack Error: Cannot find a sutable ZIP program <- an I is missing in  
 suitable ;)

CPack Error: Cannot initialize the generator


CMake-2.4.7 wants either WinZip or Info-Zip[1]. Since the latter is  
free, I use that. You get some command line programs that CMake uses  
just fine :)


HS

[1]: ftp://ftp.info-zip.org/pub/infozip/WIN32/zip232xn.zip


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] CPack

[Torsten Martinsen]

Hendrik Sattler <> wrote:

> Zitat von [EMAIL PROTECTED]:
>> I want to use the CPACK generator, but the tutorial
>> http://www.cmake.org/Wiki/CMake:Packaging_With_CPack is not quite
>> good. Perhaps somebody knows a better site.
>> 
>> When I run make with make package, then I get following error:
>> CPack Error: Cannot find a sutable ZIP program <- an I is missing in
>> suitable ;) CPack Error: Cannot initialize the generator
> 
> CMake-2.4.7 wants either WinZip or Info-Zip[1]. Since the latter is
> free, I use that.

What is not immediately obvious is that 2.4.7 *requires* zip.exe to
reside in c:/cygwin/bin.

(Bad luck if you do not have a C: drive).

-Torsten

This e-mail and any files sent with it contain information that may be 
privileged or confidential and is the property of the GateHouse Group. This 
information is intended solely for the person to whom it is addressed. If you 
are not the intended recipient, you are not authorized to read, print, retain, 
copy, disseminate, distribute, or use the message or any part thereof. If you 
have received this e-mail in error, please notify the sender immediately, and 
delete all copies of this message. In accordance with GateHouse Security 
Policy, e-mails sent or received may be monitored. 
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack

[Alexander Neundorf]

On Monday 17 September 2007 09:04, Eric Noulard wrote:
> 2007/9/17, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > Hi Eric,
> >
> > Thanks for your reply.
> >
> > > Since you are on windows you may want to try a nightly build
> > > of CMake CVS version:
> > >
> > > http://www.cmake.org/files/vCVS/
> > >
> > > It should properly handle 7zip (I think I already used it).
> > > (However THIS IS NOT a CMake VERSION just a development snapshot).
> >
> > So this is planed to be in the next released version of Cmake?

Basically everything which is now in cmake cvs will be in cmake 2.6.0, 
including all the cpack enhancements.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] CPack

[Atwood, Robert C]

 > 
> What is not immediately obvious is that 2.4.7 *requires* zip.exe to
> reside in c:/cygwin/bin.
> 
> (Bad luck if you do not have a C: drive).
> 
> -Torsten

Ooh I don't like that, is it planend to change in near future versions?
I always try to leave the C: for Microsoft stuff to reside without
interference from things like Cygwin , it seems best that way. So on
virtually any Windows machine I've been using, the cygwin is on either
D: or F:

What about using the info-zip native WIN32 binaries? Do they need to be
in that location to be found by the utility?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack

[Alexander Neundorf]

On Monday 17 September 2007 09:46, Atwood, Robert C wrote:
> > What is not immediately obvious is that 2.4.7 *requires* zip.exe to
> > reside in c:/cygwin/bin.
> >
> > (Bad luck if you do not have a C: drive).
> >
> > -Torsten
>
> Ooh I don't like that, is it planend to change in near future versions?
> I always try to leave the C: for Microsoft stuff to reside without
> interference from things like Cygwin , it seems best that way. So on
> virtually any Windows machine I've been using, the cygwin is on either
> D: or F:

I think it also checks the path.
This has been made more flexible in cmake cvs.

> What about using the info-zip native WIN32 binaries? Do they need to be
> in that location to be found by the utility?

No, it should work via PATH.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] CPack

[Alexander.Camek]

Hi,

First of all, thanks to everybody who helped me so far.
 
> CMake-2.4.7 wants either WinZip or Info-Zip[1]. Since the latter is 
> free, I use that. You get some command line programs that CMake uses 
> just fine :)

> [1]: ftp://ftp.info-zip.org/pub/infozip/WIN32/zip232xn.zip

I will test my Cpack part with Info-Zip.

BTW, is there any Cpack documents for the available commands like it is for 
Cmake? Or is the wiki tutorial the documentation like it is for Ctest?

OT, when will the cmake2.6 released?

Greetings

Alexander



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack Debian

[Robert Bielik]

Hi all,

Is there a way to prevent CPack debian backend to tar files as "sparse" 
? We have a crossdevelopment project that needs to be unpacked on distro 
having BusyBox v.1.20.2,

which does not support sparse files.

Also we need to be able to set owner/group of the extracted files (i.e. 
tar should be given the --owner and --group options).


Ideas how to achieve these objectives ?

Regards
/Rob

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CPACK variable

[Stephen Rasku]

I am using cmake/cpack 2.8.9.  We have cmake wrapped in Makefile.
CMAKE and CPACK are defined in the Makefile as the full path to the
respective executables.  Cmake is expanding the cmake definition to
the full path but cpack doesn't include the full path.  This is the
relevant section of CMakeFiles/rpm.dir/build.make.  As you can see,
cmake includes the full path but cpack does not.

CMakeFiles/rpm:
cpack
/tools/swdev/packages/cmake/cmake-2.8.9/bin/cmake -E rename
myPackage-devel.rpm myPackage-devel-1.0-3.i586-linux.rpm
/tools/swdev/packages/cmake/cmake-2.8.9/bin/cmake -E rename
myPackage-release.rpm myPackage-1.0-3.i586-linux.rpm

...Stephen
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack component

[Lars Lars]

Hello,
We are using CPack (WIX generator) to create an installer. This works fine but 
with one slight problem that the installer contains a component that I did not 
expect.
The main CMakeList.txt file includes;
SET(CPACK_COMPONENTS_ALL RUNTIME)
In a sub CMakeList.txt file I have the following line:
INSTALL(
  DIRECTORY ${DOC_PATH}
  DESTINATION ${INSTALL_DOC_DIR}
  COMPONENT DOC)
The current installer should not include this component but another installer 
will include this component.
In the cmake_install.cmake that correspond to the sub CMakeList.txt I find the 
code below. 

# Set the component getting installed.
IF(NOT CMAKE_INSTALL_COMPONENT) # true
  IF(COMPONENT) # false
MESSAGE(STATUS "Install component: \"${COMPONENT}\"")
SET(CMAKE_INSTALL_COMPONENT "${COMPONENT}")
  ELSE(COMPONENT)
SET(CMAKE_INSTALL_COMPONENT)
  ENDIF(COMPONENT)
ENDIF(NOT CMAKE_INSTALL_COMPONENT)
IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "DOC")
  FILE(...)
ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL 
"DOC")

Debugging this code, it appears "IF(NOT CMAKE_INSTALL_COMPONENT)" is true and 
"IF(COMPONENT)" is false. This means "CMAKE_INSTALL_COMPONENT" is set to empty. 
This again means "IF(NOT CMAKE_INSTALL_COMPONENT" will be true and the file(s) 
will be installed. 
So the problem seems to be rooted in the fact that "IF(COMPONENT)" is false. So 
who is responsible for setting the content of "COMPONENT" variable? 
Appreciate any help.
 
  --

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack problems.

[Axel Roebel]

Hello,

I just tried the cpack program. It failed when executing
a post_install_script which is configured to access the installed libraries
and to rename them. Unfortunately this seems to be required if one wants to
install a static and a shared library of the same name.

Here the rename script template I use

 FILE(GLOB INSTALLED_LIBNAME [EMAIL PROTECTED]@@INSTALL_LIB_DIR
@/[EMAIL PROTECTED]@*)
MESSAGE("INSTALLED_LIBNAME  [EMAIL PROTECTED]@@INSTALL_LIB_DIR
@/[EMAIL PROTECTED]@*")
MESSAGE("INSTALLED_LIBNAME  ${INSTALLED_LIBNAME}")
STRING(REPLACE "@BEFORE_RENAME@" "@AFTER_RENAME@" INSTALLED_NAME_AFTER_RENAME $
{INSTALLED_LIBNAME})
EXEC_PROGRAM(@CMAKE_COMMAND@ ARGS -E copy "${INSTALLED_LIBNAME}" "${INSTALLED_N
AME_AFTER_RENAME}")
EXEC_PROGRAM(@CMAKE_COMMAND@ ARGS -E remove "${INSTALLED_LIBNAME}")

which gets configured when running cmake. BEFORE_RENAME is the internal 
name of the static library and after rename is the name desired after 
installation.

The problem is that  CMAKE_INSTALL_PREFIX used with cpack is different from the 
CMAKE_INSTALL_PREFIX for real compilation, however, the configured Rename script
always uses the value that is appropriate for a real installation,
 which is a value that I set with FORCE
 in CMakeFiles.txt. I wonder whether there is any possibility to solve this 
issue?

Now, in fact I don't want a binary distribution I only want a source 
distribution such that
this issue would vanish automatically. However, I don't find a flag to tell 
cpack to 
only produce a  source distribution. Is this possible?

I assume with a source distribution the user will be required to first 
install cmake, wouldn't he?

Kind regards,

-- 
Axel Roebel
IRCAM Analysis/Synthesis Team

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack documentation

[Brandon J. Van Every]

There doesn't appear to be any.  Nothing in the 2.4.2 /doc directory.  
Searching Kitware wiki yields only the briefest footnotes in some ITC 
planning papers.  FAQ doesn't have anything.  Google doesn't yield 
anything.  I do gain some tidbits from searching the CMake mailing list 
archives, but the information is haphazard.  What kind of shape is CPack in?



Cheers,
Brandon Van Every

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack parameters

[Hendrik Belitz]

hi,

I'm just playing around a little bit with CPack and its features here. I 
recently used CPack for the generation of source packages, but needed to 
learn that it will just take nearly all the stuff present in the source tree 
and throws it into the archive. I assume that I can use 
CPACK_SOURCE_IGNORE_FILES and/or
CPACK_STRIP_FILES
to counter this behaviour, but since documentation is still missing, I have 
not a single idea of how to achieve this. Could anyone here give me some 
hints on this?

Regards
 Hendrik

-
Dipl.-Inform. Hendrik Belitz
Central Institute of Electronics / Zentralinstitut für Elektronik 
 Multimodal image processing workgroup / AG Multimodale Bildverarbeitung
Research Center Juelich / Forschungszentrum Jülich GmbH
D-52428 Jülich, Germany
Tel.: (++49)2461 61 8701 Fax: (++49)2461 61 3990
email: [EMAIL PROTECTED] / [EMAIL PROTECTED] (only until 
July,31th)
PLEASE NOTE: Due to a job change, I will no longer be reachable under the 
adress [EMAIL PROTECTED] after July,31th,2006
ggp-key available via http://pgpkeys.pca.dfn.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPACK on windows

[Otmane Lahlou]

Hi List,

When packaging my project, i want my project in the start menu to be 
organised

in several directories  :

In  the windows StartMenu i'd like to have something like that :

StartMenu -> Programs -> MyProject ->   Directory1 -> {My stuffs 1}
  
Directory2 -> {My stuffs 2}

  Uninstall

Here what i did : 
- I edit the variable CPACK_PACKAGE_EXECUTABLES with the executables 
name and their label :

   "exe1"  "Description of exe1"

- In case of Windows, i  used CPACK_NSIS_MENU_LINKS to have my 
shortcuts in the startmenu.
  Here is the point; i did not succed to use this macro to get the 
subdirectories organisation.

  but i have all the executables in the root directory MyProject :

 StartMenu -> Programs -> MyProject ->   My stuffs 1
   My 
stuffs 2
   
Uninstall


Any hints to do that?
Thanks

Otmane
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Andreas Mohr]

On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-requ...@cmake.org wrote:
> Date: Wed, 22 Dec 2010 09:57:11 -0800
> From: KC Jones 
> Subject: [CMake] CPack 101

> And I just don't seem to get it. I know this is very possible.  I know this 
> is my own problem, first and foremost.  So I'm exposing myself to potential 
> criticism here since RTFM and "get a clue" are probably the biggest part of 
> fixing my problem.  Im not really asking for specific help on my code - I 
> might ask for that later.  For now I just want to vent, hopefully in a 
> constructive way.

I have nothing to add about your particular description, but let me just
say that I can fully relate to how you feel, given that I hit a truly-WTF
situation just yesterday, too:

convert (imagemagick) appears to have incompatible versions which write
to either file.xpm.0 or file-0.xpm (and there's no option to specify
a specific file name prefix/format for icon series).

So, to convert an icon file, add an add_custom_command().
The problem then becomes how to know which file to choose
for subsequent COMMAND lines,
given that EITHER the one OR the other output file naming
is available after conversion.

- there's no cmake -E rename available (perhaps for reasons of build rule 
atomicity)
- trying to use cmake -E copy will FAIL for one of the two file name
  candidates, causing target processing to ABORT (thus cmake -E rename
  wouldn't be better ;)
- trying to detect file existence (e.g. via stat) within
  add_custom_command() processing is not possible either (how to branch
  based on the result? ok, perhaps doable via a chain of targets...)
- I settled on COMMAND sh -c '(mv -f src_a dest || mv -f src_b dest)',
  however that also is very problematic since sh -c is for
  single-command execution, not for composite commands
  (and, indeed, thus will work on RHEL5 and readily fail on Mac OS X)
- so, decided to use a file(WRITE ...) to actually on-demand-write the
  entire add_custom_command() content as a shell script
  (which actually seems more suitable since it elegantly merges multiple
   COMMAND lines into a simple shell script)
- no go, since file(WRITE) always uses Windows newlines (there's no builtin
  dos2unix support in CMake nor a support module which provides nicely
abstracted access to dos2unix, tofrodos, tr or other suitable tools,
  nor an - admittedly architecturally not really desireable - hard-coded 
builtin way
  for file(WRITE) to specify that one wants UNIX line feeds)
- no go, since file(WRITE) result has wrong permissions (that one could be fixed
  via some additional magic involving configure_file() etc.)
- so, perhaps use an existing shell script template via
  configure_file(), then adjust permissions?
- that's impossible due to using that @!#$^#3)+...@! RCS abomination called VSS
  (yes, in TWO-THOUSAND-AND-TEN, still!) via SOS which is unable
   to provide any support for line feeds and permissions
  (but this admittedly is also a somewhat more complex topic in e.g. git or SVN)
- could have _manually_ added in configuration for dos2unix functionality
  (and in fact I'm using it somewhere else already),
  but this SHOULD NOT BE NEEDED (we _are_ on a UNIX platform and thus
  there _should_ be some builtin aid for that) and thus I bailed at adding
  complicated support lines for that
- finally, due to having to find a solution due to the Mac OS X issue
  mentioned above, chose to use
  COMMAND sh -c 'cat file.xpm.0 file-0.xpm > result.xpm'
- cat FAILED due to one of the two files not being available
  (and cat -f is not available.)
- thus used the laughably incredible workaround of
  COMMAND "${CMAKE_COMMAND} -E touch file.xpm.0"
  COMMAND "${CMAKE_COMMAND} -E touch file-0.xpm"
  COMMAND sh -c 'cat file.xpm.0 file-0.xpm > result.xpm'


That's 13 items of descriptions of failure (and I'm sure I forgot to
list some other failed avenues which I had been thinking about).

YUCK.


I don't know what the perfect answer here is (or possibly I'm just blind
for it?), but I know for certain that a simple Makefile rule
would have a lot more flexibility / simplicity,
and this simplicity is what CMake should strive to match
while keeping its current very nice full generator/platform abstraction.
Yes, of course that's hard, but IMHO the above story clearly shows that
_something_ appears to be much too involved about it, since there was
exactly no help at all anywhere, to defuse the situation to enable me
to reach a satisfying result. IOW implementation pressure due to
multiple CMake constraints is __MUCH__ too high, e.g. in the realms of line
feeds / permissions / symlinks especially (multiple discussion threads on the
internet about this).

To put it simply, I was just not happy the entire time while
trying to implement this and not finding any satisfying (well-crafted) solutio

Re: [CMake] CPack 101

[Andreas Pakulat]

On 22.12.10 23:24:35, Andreas Mohr wrote:
> - there's no cmake -E rename available (perhaps for reasons of build rule 
> atomicity)

Hmm my cmake -E help tells me different:
  ...
  rename oldname newname- rename a file or directory (on one volume)
  ...

This is cmake version 2.8.2.20100804-ga42a4

Andreas

-- 
You will be singled out for promotion in your work.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Mike McQuaid]

To start with, Charm might be a good example of how to use CPack, it's
an internal tool we've written in Qt and use CPack to do all the
packaging:
https://github.com/KDAB/Charm

Check particularly the CMakeLists.txt and Charm/CMakeLists.txt for all
the CPack-relevant logic.


On 22 December 2010 17:57, KC Jones  wrote:
> I just don't think that CPack documentation and examples as they currently
> are published are sufficient or effective.

I completely agree.

> More CPack example and tutorials would be very helpful.  I see from archive
> searches that I'm not the first to suggest this.  The Qt example is great,
> but the plugin support is overkill for most, and obfuscates much of the rest
> of the example.
> A step-wise tutorial format that starts with a working build, adds install
> target support, then adds CPack code would help my addled brain.  Presenting
> newbies like me with a fully baked end result is helpful, but somewhat hard
> to digest.

Agreed.


> A glossary, please.  For instance "bundle" comes out of OS X, but now has
> some CMake-specific meaning for Linux and Win that I know is very important
> to me, but fully incomprehensible in my reading so far.  Oh, and what are
> bundle keys?

BundleUtilities is a really bad name. As I've said before, the naming
stops Windows and Linux people from finding this functionality until
they post on the mailing list or bugtracker. It's worth remembering
that 90% (if not more) people won't even get here and will just use
another tool.

BundleUtilities/GetPrerequisites should really be rolled into CPack,
I'd be pretty amazed if many people were using it outside of CPack.


> More meta docs please.  Somewhere in my stumbling I found a decent diagram
> about how the ExternalProject module works.  I think it was on the wiki, but
> I can't find it now.  I would die for something similar that shows what
> install does and how it integrates with CPack.  Same goes for BudleUtilities
> and other modules I've yet to discover.

Really what's needed is less API documentation and more workflow
documentation, perhaps based around user stories. If I just want to
set up a CMake project and build a package there should be a
step-by-step walk through the documentation.


> One final comment, cmake is elegant in the extreme.  I can see from some of
> the wiki pages about how install is a merge that canonically folds multiple
> precursors into one uber-powerful, uber-flexible silver bullet.  Impressive
> I'm sure.  But harder to grok.  I'm not suggesting that this is a wrong
> choice.  But it is a barrier to learning.  Where there is this kind of
> folding of advanced features into basic operations, some care is needed to
> ensure the docs convey the basics clearly.

Agreed.

> WRT Cpack, what I find is that by merging it into CMake, the CPack code is
> declared one step away from where it is applied.  The need for careful
> quoting in install(CODE ) blocks is a case in point.  I'm sure this folding
> into a canonical, unified single CMakeLists.txt source is a good thing.  But
> right now I feel like I'm learning Lisp again.  Kind of mind blowing.
>  Wishing I had some better training wheels to break this down for me...
> Thanks for your indulgence.  I hope this does not offend those who've put so
> much into this great tool.

I think integrating CPack into CMake is good but it hasn't been done
very well. INSTALL(CODE) is just a mess and it would be good to be
able to interact with CPack for typical usecases (e.g. use
BundleUtilities to install all dependencies of an executable only at
package time) and roll this into normal CPack syntax.

I think the biggest problem is that people complain about CPack not
being easy to use and are simply told how to do the task they've had
the problem with and the bug/mail is ignored. The problem isn't the
CPack functionality, it's accessing it and the lack of discoverability
of it's features.

I want to try and help and write patches for this stuff but I create
bugs and they are ignored and then post on the mailing list and no-one
from Kitware comments. I really appreciate that everyone is very busy
but it feels like the CPack developers think it's good enough as-is
and aren't particularly interested in attracted new contributions and
improving the project.



-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Mike McQuaid]

On 22 December 2010 22:24, Andreas Mohr  wrote:
> To put it simply, I was just not happy the entire time while
> trying to implement this and not finding any satisfying (well-crafted) 
> solution,
> only ugly, very bad or semi-failing workarounds.
> That kind of work should be _fun_, especially when it then results in a
> nicely working and fully automated result. It plain wasn't.

It's hard to understand exactly what your problems are other than just
learning CMake. I suggest you make a new thread and try and explain
these clearly, it's pretty hard to try and help from your previous
descriptions.

> I have to say that so far I'm quite happy with the sufficiently large
> infrastructure that I was able to create, it's just that many areas
> feel wanting (the entire BundleUtilities / install-time stuff
> is an example of that, too).

I agree. I think the install-time/CPack/dependency stuff needs some work.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Michael Wild]

On 12/22/2010 11:24 PM, Andreas Mohr wrote:
> On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-requ...@cmake.org wrote:
>> Date: Wed, 22 Dec 2010 09:57:11 -0800
>> From: KC Jones 
>> Subject: [CMake] CPack 101
> 
>> And I just don't seem to get it. I know this is very possible.  I know this 
>> is my own problem, first and foremost.  So I'm exposing myself to potential 
>> criticism here since RTFM and "get a clue" are probably the biggest part of 
>> fixing my problem.  Im not really asking for specific help on my code - I 
>> might ask for that later.  For now I just want to vent, hopefully in a 
>> constructive way.
> 
> I have nothing to add about your particular description, but let me just
> say that I can fully relate to how you feel, given that I hit a truly-WTF
> situation just yesterday, too:
> 
> convert (imagemagick) appears to have incompatible versions which write
> to either file.xpm.0 or file-0.xpm (and there's no option to specify
> a specific file name prefix/format for icon series).

That is a bug in imagemagick then. Of course, you could do a
configure-check at CMake-time and figure out what naming scheme it uses
and then create your rules accordingly.

> 
> So, to convert an icon file, add an add_custom_command().
> The problem then becomes how to know which file to choose
> for subsequent COMMAND lines,
> given that EITHER the one OR the other output file naming
> is available after conversion.
> 

[SNIP long list of failures]

> 
> 
> That's 13 items of descriptions of failure (and I'm sure I forgot to
> list some other failed avenues which I had been thinking about).
> 
> YUCK.
> 
> 
> I don't know what the perfect answer here is (or possibly I'm just blind
> for it?), but I know for certain that a simple Makefile rule
> would have a lot more flexibility / simplicity,
> and this simplicity is what CMake should strive to match
> while keeping its current very nice full generator/platform abstraction.
> Yes, of course that's hard, but IMHO the above story clearly shows that
> _something_ appears to be much too involved about it, since there was
> exactly no help at all anywhere, to defuse the situation to enable me
> to reach a satisfying result. IOW implementation pressure due to
> multiple CMake constraints is __MUCH__ too high, e.g. in the realms of line
> feeds / permissions / symlinks especially (multiple discussion threads on the
> internet about this).
> 

You missed the obvious solution, as described above. Another solution is
that CMake is also a script-interpreter, and you can write arbitrary
scripts in the CMake language and then invoke them with ${CMAKE_COMMAND}
-P some_script.cmake in a custom command. In there you can do the full
thing: if(EXISTS ...), file(RENAME ...) etc.

Besides, simple Makefile rules won't help you on platforms without a
POSIX shell (e.g. Windows), so that would be even worse.

> To put it simply, I was just not happy the entire time while
> trying to implement this and not finding any satisfying (well-crafted) 
> solution,
> only ugly, very bad or semi-failing workarounds.
> That kind of work should be _fun_, especially when it then results in a
> nicely working and fully automated result. It plain wasn't.
> 
> I also recently witnessed a discussion (was it libusb?)
> where a suggestion for CMake build support was met with a clear number of
> replies tending away from it, likely due to similar experience. Unfortunately.

I'm not familiar with that particular discussion, but the usual FUD goes
along the lines that people don't want "yet another butt-ugly language".
Well, CMake language might not win a beauty contest, granted, but
ignoring the fact that the wide-spread autohell crap is a wild jumble of
POSIX-shell, Automake and, by far ugliest of all languages, M4. This
makes a total of 3 difficult to learn languages! So, replacing autohell
by CMake is actually a decrease by 2 languages, one of which must be the
most irritating and sadistic language ever invented (apart from
brainf*ck, that is).

> 
> Hopefully my story will enable people to see where there are problems
> and how to approach any potential solutions.
> 
> I have to say that so far I'm quite happy with the sufficiently large
> infrastructure that I was able to create, it's just that many areas
> feel wanting (the entire BundleUtilities / install-time stuff
> is an example of that, too).

I agree, the BundleUtilities need much more precise documentation.

> 
> Thanks,
> 
> Andreas Mohr

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[David Cole]

On Wed, Dec 22, 2010 at 12:57 PM, KC Jones  wrote:

> Feeling really uneasy about putting this out there, but here goes...
>
> I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and
> Linux (Ubuntu 10.04).
> The app depends on some libraries (Qt4.6 (no plugins) and a customized
> build of Poco).
> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt +
> Poco lib packaging)
> On Linux, I want a Debian package to install the Poco libs at a minimum
> along with my executable.
> Equivalent Windows installers will be needed someday.
>
> I've reviewed the docs at
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html
> I've reviewed bits and pieces on the wiki:
> http://www.cmake.org/Wiki/BundleUtilitiesExample
> http://www.cmake.org/Wiki/CMake#CPack
>
> And I just don't seem to get it. I know this is very possible.  I know this
> is my own problem, first and foremost.  So I'm exposing myself to potential
> criticism here since RTFM and "get a clue" are probably the biggest part of
> fixing my problem.  Im not really asking for specific help on my code - I
> might ask for that later.  For now I just want to vent, hopefully in a
> constructive way.
>
> I just don't think that CPack documentation and examples as they currently
> are published are sufficient or effective.
>
>
Neither do we:
http://public.kitware.com/Bug/view.php?id=10067


A few suggestions:
>
>- More CPack example and tutorials would be very helpful.  I see from
>archive searches that I'm not the first to suggest this.  The Qt example is
>great, but the plugin support is overkill for most, and obfuscates much of
>the rest of the example.
>- A step-wise tutorial format that starts with a working build, adds
>install target support, then adds CPack code would help my addled brain.
> Presenting newbies like me with a fully baked end result is helpful, but
>somewhat hard to digest.
>- Separating the docs into different namespaces (Cmake, CPack,
>CTest...) might be more effective.  I struggled a long while before finding
>the install command docs (which I continue to struggle with). The atomic
>layout of the docs obscures the module-level relationships.
>- A glossary, please.  For instance "bundle" comes out of OS X, but now
>has some CMake-specific meaning for Linux and Win that I know is very
>important to me, but fully incomprehensible in my reading so far.  Oh, and
>what are bundle keys?
>- More meta docs please.  Somewhere in my stumbling I found a decent
>diagram about how the ExternalProject module works.  I think it was on the
>wiki, but I can't find it now.  I would die for something similar that 
> shows
>what install does and how it integrates with CPack.  Same goes for
>BudleUtilities and other modules I've yet to discover.
>
>
As always, as developers we find ourselves constantly working to improve
what we have: fixing bugs, implementing new features, answering questions on
the mailing list, blogging/communicating about it, adding examples and
suggestions to the Wiki.

The struggle is reserving enough time to contribute to documentation when
there are always "real" (functional) bugs to be fixed. Perpetual questions:
what's "enough" documentation?, how do we make sure people can find it
easily?, how do we name this better (but still preserve the existing names
for people already using it / backwards compatibility)?

I make no excuses here: yes, the CPack and CTest documentation are lacking /
lagging behind the CMake documentation. However, it will take a very real
and concerted and time-consuming effort to improve the situation. With the
open source nature of the project, we have to be willing to accept the
organic growth that occurs in the code base: the documentation will be the
same: it will improve gradually, over time, as contributors are able to
improve it.

Until then, at least the mailing list has a reasonable response rate and, it
seems, sufficient participation from knowledgeable folks willing to pitch in
and answer. So... if you're confused about something, please ask here.



> One final comment, cmake is elegant in the extreme.  I can see from some of
> the wiki pages about how install is a merge that canonically folds multiple
> precursors into one uber-powerful, uber-flexible silver bullet.  Impressive
> I'm sure.  But harder to grok.  I'm not suggesting that this is a wrong
> choice.  But it is a barrier to learning.  Where there is this kind of
> folding of advanced features into basic operations, some care is needed to
> ensure the docs convey the basics clearly.
>
> WRT Cpack, what I find is that by merging i

Re: [CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 12:43, David Cole  wrote:
> Neither do we:
> http://public.kitware.com/Bug/view.php?id=10067

> As always, as developers we find ourselves constantly working to improve
> what we have: fixing bugs, implementing new features, answering questions on
> the mailing list, blogging/communicating about it, adding examples and
> suggestions to the Wiki.
>
> The struggle is reserving enough time to contribute to documentation when
> there are always "real" (functional) bugs to be fixed. Perpetual questions:
> what's "enough" documentation?, how do we make sure people can find it
> easily?, how do we name this better (but still preserve the existing names
> for people already using it / backwards compatibility)?

> I make no excuses here: yes, the CPack and CTest documentation are lacking /
> lagging behind the CMake documentation. However, it will take a very real
> and concerted and time-consuming effort to improve the situation. With the
> open source nature of the project, we have to be willing to accept the
> organic growth that occurs in the code base: the documentation will be the
> same: it will improve gradually, over time, as contributors are able to
> improve it.

I think the main problem is that you make it very hard for people to
contribute. KDE and Homebrew (two other open-source projects I've
written a lot of code for over the years) make this very easy.

Kitware is great, you clearly write good code and have done a great
job creating CMake and CPack. They are fantastic tools. However, I
think until you are more encouraging of external developers you will
struggle to make huge improvements to CMake.


> Until then, at least the mailing list has a reasonable response rate and, it
> seems, sufficient participation from knowledgeable folks willing to pitch in
> and answer. So... if you're confused about something, please ask here.
> We (I hope I speak for all CMake devs, here) take no offense. We welcome
> discussion, always.

The mailing list is OK but most people don't want to sign up to a
mailing list and receive lots of emails that have nothing to do with
them. I'm only signed up because I want to try and get some patches
merged and was told that I should discuss things here rather than the
bugtracker.

I hope I don't cause any offense here either. I'm passionate about
CMake because I like the tool and want to make it better.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Johan Björk]

On Thu, Dec 23, 2010 at 1:43 PM, David Cole  wrote:

> On Wed, Dec 22, 2010 at 12:57 PM, KC Jones  wrote:
>
>> Feeling really uneasy about putting this out there, but here goes...
>>
>> I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and
>> Linux (Ubuntu 10.04).
>> The app depends on some libraries (Qt4.6 (no plugins) and a customized
>> build of Poco).
>> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt +
>> Poco lib packaging)
>> On Linux, I want a Debian package to install the Poco libs at a minimum
>> along with my executable.
>> Equivalent Windows installers will be needed someday.
>>
>> I've reviewed the docs at
>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html
>> I've reviewed bits and pieces on the wiki:
>> http://www.cmake.org/Wiki/BundleUtilitiesExample
>> http://www.cmake.org/Wiki/CMake#CPack
>>
>> And I just don't seem to get it. I know this is very possible.  I know
>> this is my own problem, first and foremost.  So I'm exposing myself to
>> potential criticism here since RTFM and "get a clue" are probably the
>> biggest part of fixing my problem.  Im not really asking for specific help
>> on my code - I might ask for that later.  For now I just want to vent,
>> hopefully in a constructive way.
>>
>> I just don't think that CPack documentation and examples as they currently
>> are published are sufficient or effective.
>>
>>
> Neither do we:
> http://public.kitware.com/Bug/view.php?id=10067
>
>
> A few suggestions:
>>
>>- More CPack example and tutorials would be very helpful.  I see from
>>archive searches that I'm not the first to suggest this.  The Qt example 
>> is
>>great, but the plugin support is overkill for most, and obfuscates much of
>>the rest of the example.
>>- A step-wise tutorial format that starts with a working build, adds
>>install target support, then adds CPack code would help my addled brain.
>> Presenting newbies like me with a fully baked end result is helpful, but
>>somewhat hard to digest.
>>- Separating the docs into different namespaces (Cmake, CPack,
>>CTest...) might be more effective.  I struggled a long while before 
>> finding
>>the install command docs (which I continue to struggle with). The atomic
>>layout of the docs obscures the module-level relationships.
>>- A glossary, please.  For instance "bundle" comes out of OS X, but
>>now has some CMake-specific meaning for Linux and Win that I know is very
>>important to me, but fully incomprehensible in my reading so far.  Oh, and
>>what are bundle keys?
>>- More meta docs please.  Somewhere in my stumbling I found a decent
>>diagram about how the ExternalProject module works.  I think it was on the
>>wiki, but I can't find it now.  I would die for something similar that 
>> shows
>>what install does and how it integrates with CPack.  Same goes for
>>BudleUtilities and other modules I've yet to discover.
>>
>>
> As always, as developers we find ourselves constantly working to improve
> what we have: fixing bugs, implementing new features, answering questions on
> the mailing list, blogging/communicating about it, adding examples and
> suggestions to the Wiki.
>
> The struggle is reserving enough time to contribute to documentation when
> there are always "real" (functional) bugs to be fixed. Perpetual questions:
> what's "enough" documentation?, how do we make sure people can find it
> easily?, how do we name this better (but still preserve the existing names
> for people already using it / backwards compatibility)?
>
> I make no excuses here: yes, the CPack and CTest documentation are lacking
> / lagging behind the CMake documentation. However, it will take a very real
> and concerted and time-consuming effort to improve the situation. With the
> open source nature of the project, we have to be willing to accept the
> organic growth that occurs in the code base: the documentation will be the
> same: it will improve gradually, over time, as contributors are able to
> improve it.
>
> Until then, at least the mailing list has a reasonable response rate and,
> it seems, sufficient participation from knowledgeable folks willing to pitch
> in and answer. So... if you're confused about something, please ask here.
>
> How about a search for the mailinglist archives?


>
>> One final comment, cmake is elegant in the extreme.  I can see from some
>> of the w

Re: [CMake] CPack 101

[David Cole]

On Thu, Dec 23, 2010 at 7:58 AM, Mike McQuaid  wrote:

> On 23 December 2010 12:43, David Cole  wrote:
> > Neither do we:
> > http://public.kitware.com/Bug/view.php?id=10067
>
> > As always, as developers we find ourselves constantly working to improve
> > what we have: fixing bugs, implementing new features, answering questions
> on
> > the mailing list, blogging/communicating about it, adding examples and
> > suggestions to the Wiki.
> >
> > The struggle is reserving enough time to contribute to documentation when
> > there are always "real" (functional) bugs to be fixed. Perpetual
> questions:
> > what's "enough" documentation?, how do we make sure people can find it
> > easily?, how do we name this better (but still preserve the existing
> names
> > for people already using it / backwards compatibility)?
>
> > I make no excuses here: yes, the CPack and CTest documentation are
> lacking /
> > lagging behind the CMake documentation. However, it will take a very real
> > and concerted and time-consuming effort to improve the situation. With
> the
> > open source nature of the project, we have to be willing to accept the
> > organic growth that occurs in the code base: the documentation will be
> the
> > same: it will improve gradually, over time, as contributors are able to
> > improve it.
>
> I think the main problem is that you make it very hard for people to
> contribute. KDE and Homebrew (two other open-source projects I've
> written a lot of code for over the years) make this very easy.
>
>
How do we make it very hard? What about KDE and Homebrew make this very
easy? Specifics, please.

Kitware is great, you clearly write good code and have done a great
> job creating CMake and CPack. They are fantastic tools. However, I
> think until you are more encouraging of external developers you will
> struggle to make huge improvements to CMake.
>

Thank you. Even with more external developers, I think we'll struggle --
that would just be a different sort of struggle.



> > Until then, at least the mailing list has a reasonable response rate and,
> it
> > seems, sufficient participation from knowledgeable folks willing to pitch
> in
> > and answer. So... if you're confused about something, please ask here.
> > We (I hope I speak for all CMake devs, here) take no offense. We welcome
> > discussion, always.
>
> The mailing list is OK but most people don't want to sign up to a
> mailing list and receive lots of emails that have nothing to do with
> them. I'm only signed up because I want to try and get some patches
> merged and was told that I should discuss things here rather than the
> bugtracker.
>
> I hope I don't cause any offense here either. I'm passionate about
> CMake because I like the tool and want to make it better.
>
>
Again, let me stress, no offense taken. There is no way you can offend me,
unless you start calling me names for no reason. Reasonable discussion
always welcome.

Thx,
David



> --
> Mike McQuaid
> http://mikemcquaid.com
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[David Cole]

On Thu, Dec 23, 2010 at 8:23 AM, Johan Björk  wrote:

>
>
> On Thu, Dec 23, 2010 at 1:43 PM, David Cole wrote:
>
>> On Wed, Dec 22, 2010 at 12:57 PM, KC Jones  wrote:
>>
>>> Feeling really uneasy about putting this out there, but here goes...
>>>
>>> I have an app that I am building with cmake (2.8) on both Mac (10.6.40
>>> and Linux (Ubuntu 10.04).
>>> The app depends on some libraries (Qt4.6 (no plugins) and a customized
>>> build of Poco).
>>> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt
>>> + Poco lib packaging)
>>> On Linux, I want a Debian package to install the Poco libs at a minimum
>>> along with my executable.
>>> Equivalent Windows installers will be needed someday.
>>>
>>> I've reviewed the docs at
>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html
>>> I've reviewed bits and pieces on the wiki:
>>> http://www.cmake.org/Wiki/BundleUtilitiesExample
>>> http://www.cmake.org/Wiki/CMake#CPack
>>>
>>> And I just don't seem to get it. I know this is very possible.  I know
>>> this is my own problem, first and foremost.  So I'm exposing myself to
>>> potential criticism here since RTFM and "get a clue" are probably the
>>> biggest part of fixing my problem.  Im not really asking for specific help
>>> on my code - I might ask for that later.  For now I just want to vent,
>>> hopefully in a constructive way.
>>>
>>> I just don't think that CPack documentation and examples as they
>>> currently are published are sufficient or effective.
>>>
>>>
>> Neither do we:
>> http://public.kitware.com/Bug/view.php?id=10067
>>
>>
>> A few suggestions:
>>>
>>>- More CPack example and tutorials would be very helpful.  I see from
>>>archive searches that I'm not the first to suggest this.  The Qt example 
>>> is
>>>great, but the plugin support is overkill for most, and obfuscates much 
>>> of
>>>the rest of the example.
>>>- A step-wise tutorial format that starts with a working build, adds
>>>install target support, then adds CPack code would help my addled brain.
>>> Presenting newbies like me with a fully baked end result is helpful, but
>>>somewhat hard to digest.
>>>- Separating the docs into different namespaces (Cmake, CPack,
>>>CTest...) might be more effective.  I struggled a long while before 
>>> finding
>>>the install command docs (which I continue to struggle with). The atomic
>>>layout of the docs obscures the module-level relationships.
>>>- A glossary, please.  For instance "bundle" comes out of OS X, but
>>>now has some CMake-specific meaning for Linux and Win that I know is very
>>>important to me, but fully incomprehensible in my reading so far.  Oh, 
>>> and
>>>what are bundle keys?
>>>- More meta docs please.  Somewhere in my stumbling I found a decent
>>>diagram about how the ExternalProject module works.  I think it was on 
>>> the
>>>wiki, but I can't find it now.  I would die for something similar that 
>>> shows
>>>what install does and how it integrates with CPack.  Same goes for
>>>BudleUtilities and other modules I've yet to discover.
>>>
>>>
>> As always, as developers we find ourselves constantly working to improve
>> what we have: fixing bugs, implementing new features, answering questions on
>> the mailing list, blogging/communicating about it, adding examples and
>> suggestions to the Wiki.
>>
>> The struggle is reserving enough time to contribute to documentation when
>> there are always "real" (functional) bugs to be fixed. Perpetual questions:
>> what's "enough" documentation?, how do we make sure people can find it
>> easily?, how do we name this better (but still preserve the existing names
>> for people already using it / backwards compatibility)?
>>
>> I make no excuses here: yes, the CPack and CTest documentation are lacking
>> / lagging behind the CMake documentation. However, it will take a very real
>> and concerted and time-consuming effort to improve the situation. With the
>> open source nature of the project, we have to be willing to accept the
>> organic growth that occurs in the code base: the documentation will be the
>> same: it will improve gradually, over time, as contributors are able to
&

Re: [CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 13:24, David Cole  wrote:
> How do we make it very hard? What about KDE and Homebrew make this very
> easy? Specifics, please.

Firstly, http://producingoss.com/ is a great read.

Specifically though, Homebrew is pretty much the golden child of
encouraging external contribution. We're the most forked repo on
Github, the 6th most watched and have had 719 code contributors in
about a year and a half of existing. We've managed this with only 4
people with commit access, all of whom have full-time jobs in the
industry working on other projects.

I think Github and DVCS really allows you to scale well. If you
publish decent guidelines for how people can contribute and use e.g.
pull requests on Github or similar Git mechanisms then you can have
incredibly quick workflows for viewing, mergeing, testing and pushing
user code.

I have an alias "bpi" in my shell which downloads from a pull request
or user repository commit on Github, applies it to my local
repository, shows me the changes and installs the relevant changes
packages. Once I type "git push" this is now shared with everyone
using the project.

I think for you guys general guidelines on what patches would/wouldn't
be accepted would be a good start. Documentation of your coding
standards and what I should do to test my work before submitting it
would help too. I can guess a fair amount because I've contributed to
a lot of open-source projects but others might not do the same.

I think the main thing that I find lacking here though is
responsiveness to suggestions. When I make one, I need to keep poking
again and again until I receive I response. Other things include
specific code review of patches and a quick "this functionality
would/wouldn't be accepted" when suggestions are made so I know
whether to work on it or not.

I think using Git/Github in your workflow could help with part of this
but a certain amount will need to be responding to users, either
through your current bug tracker, a better one or Github's issue
tracker.

Another option that might help is a cmake-dev mailing list that is
only for discussing development issues rather than users seeking help.

Just a few ideas for you. Hopefully some of them are useful. I'm more
than willing to discuss this in further depth, either here, personal
mail or at an open-source conference (next one I'll definitely be at
will be the KDE one in Berlin 2011).


> Thank you. Even with more external developers, I think we'll struggle --
> that would just be a different sort of struggle.

Sure, it will probably involve more reviewing/mentoring but less code writing.


> Again, let me stress, no offense taken. There is no way you can offend me,
> unless you start calling me names for no reason. Reasonable discussion
> always welcome.

So can I call you names as long as I have a good reason? ;)

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Bill Hoffman]

On 12/23/2010 8:44 AM, Mike McQuaid wrote:

On 23 December 2010 13:24, David Cole  wrote:

How do we make it very hard? What about KDE and Homebrew make this very
easy? Specifics, please.




I think for you guys general guidelines on what patches would/wouldn't
be accepted would be a good start. Documentation of your coding
standards and what I should do to test my work before submitting it
would help too. I can guess a fair amount because I've contributed to
a lot of open-source projects but others might not do the same.

I think the main thing that I find lacking here though is
responsiveness to suggestions. When I make one, I need to keep poking
again and again until I receive I response. Other things include
specific code review of patches and a quick "this functionality
would/wouldn't be accepted" when suggestions are made so I know
whether to work on it or not.

I think using Git/Github in your workflow could help with part of this
but a certain amount will need to be responding to users, either
through your current bug tracker, a better one or Github's issue
tracker.

Another option that might help is a cmake-dev mailing list that is
only for discussing development issues rather than users seeking help.



Something like this perhaps:

http://www.cmake.org/cmake/help/mailing.html
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


The way I see it, there are two types of contributions.

1. You have already written some code that does something you need for 
your project.


2. You have a suggestion for a change that you would like to see but 
have not done.



These two cases are treated differently.  Here is the workflow I would 
would like to see for them:


1. you have some code.
   The biggest thing that slows down adoption of new code in CMake is 
lack of testing.   New features that are not tested, are not welcome 
into CMake.  If the code has a CMake test and there is good dashboard 
coverage for the test, then the code will be adopted much quicker.  The 
code can be done on github or gitorious.org, or just a patch attached to 
a bug entry in the CMake bug tracker.  If a cmake developer can just 
merge in the code, and run ctest to test the new code, it makes it very 
easy to commit.


2. You have a suggestion for a change but no code.
I think there are two sub-cases for this as well:
  A. You are willing to write the code yourself.
  B. You think that someone else should write it for you.

For A, you would want to get buy in from the developers and community 
before starting the code.  For this the cmake-developers mailing list 
would be the place to start.  Although, sometimes it might make sense to 
float the idea on the cmake mailing list first to see what the community 
things, and then use the developers list for implementation details.


For B, you have to do a pretty good sales job for the work to be done. 
You are basically asking for a handout.  Kitware does not directly 
invest in CMake, new features developed by Kitware come from Kitware 
customers requesting them.  So, you can hire Kitware (become a 
customer), or if your suggestion lines up with the needs of an existing 
customer, you might get lucky.  Of course Kitware people are not the 
only ones developing CMake, you might be able to convince someone else 
to do the work.  Either way, this is the hardest type of change to have 
made.


In summary, Kitware and the CMake developers outside Kitware have been 
working on being more inclusive.  We realize that our process needs to 
include more of the community.  Recently we have made several changes in 
order to include more outside help on the CMake project.  Those changes 
are as follows:


1. We moved to git

2. We moved to a quarterly release schedule.

3. After each release we send out and email to the cmake and 
cmake-developers list, and ask for people to suggest the things they 
would like to see in the next release.  Here is the current list:
http://public.kitware.com/Bug/roadmap_page.php.  Next release is 
scheduled for Jan. 10.


4. We have directed all new bugs on the bug tracker to the 
cmake-developers list.  This allows all developers to see new issues as 
they come in.


5. We have made an effort to clean up old stuff in the bug tracker.


So, if you have time that you want to spend on CMake development, join 
the cmake-developers mailing list.  Write some tested, documented code 
and contribute it.


Thanks.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Raymond Wan]

Hi Mike and all,


On Thu, Dec 23, 2010 at 21:58, Mike McQuaid  wrote:
> On 23 December 2010 12:43, David Cole  wrote:
> I think the main problem is that you make it very hard for people to
> contribute. KDE and Homebrew (two other open-source projects I've
> written a lot of code for over the years) make this very easy.
>
> Kitware is great, you clearly write good code and have done a great
> job creating CMake and CPack. They are fantastic tools. However, I
> think until you are more encouraging of external developers you will
> struggle to make huge improvements to CMake.


As only a casual user of CMake, I'm hesitant to enter this kind of
thread, but a comment like the above is difficult to ignore.  :-)

IMHO, the comparison between KDE and CMake is a bit unfair.  KDE is
visible to many people, both developers and users, while CMake is
known by only developers.  Also, it is known that CMake is developed
by Kitware; this is quite different from KDE which relies on a very
large international community.  So, combining these two reasons, it is
not so surprising that the management of how KDE is developed is more
advanced.

Yes, they are both open-source, but two software can be both
open-source but still be run differently.  It isn't necessary for one
open-source software to be managed similar to another one.  And I
think (without knowing the actual numbers) that the code to KDE is
larger than CMake?

Personally, the help I've seen on this mailing list and in the mailing
list archives is great and while there may be room for improvement, I
guess it can happen in time.



> The mailing list is OK but most people don't want to sign up to a
> mailing list and receive lots of emails that have nothing to do with
> them. I'm only signed up because I want to try and get some patches
> merged and was told that I should discuss things here rather than the
> bugtracker.
>
> I hope I don't cause any offense here either. I'm passionate about
> CMake because I like the tool and want to make it better.


Someone else has talked about using Google on the archives.

An often ignored point is that thanks to Google, you can "contribute"
to the documentation just by writing a web page.  If it is useful and
gets linked by others, etc., then the right keywords will make your
web page appear on the first page of Google's results.  Some of the
help I've got on CMake, CPack, etc. are on non-cmake pages, actually.
Of course, if these pages are wrong, then the error propagates...  But
if it is useful, I guess Kitware developers will be happy to include
it in the Wiki at least?

Ray
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Michael Wild]

On 12/23/2010 02:44 PM, Mike McQuaid wrote:
> On 23 December 2010 13:24, David Cole  wrote:
>> How do we make it very hard? What about KDE and Homebrew make this very
>> easy? Specifics, please.
> 
> Firstly, http://producingoss.com/ is a great read.
> 
> Specifically though, Homebrew is pretty much the golden child of
> encouraging external contribution. We're the most forked repo on
> Github, the 6th most watched and have had 719 code contributors in
> about a year and a half of existing. We've managed this with only 4
> people with commit access, all of whom have full-time jobs in the
> industry working on other projects.

Well, I also did some contributions to homebrew, and I have to agree
that patches get picked up really quickly. There's one big "but",
though: Writing a formula is fairly simple. Just copy an existing
formula that is similar to your favourite package, adapt it, build,
commit and push. Many contributions are even much simpler: just update
the version number, done. The learning curve is extremely low. Also,
Homebrew is Mac-only, so contributors don't have to worry about all the
exotic platforms out there. They are geeks and nerds who like to build
stuff themselves. I'd bet that almost everybody using Homebrew is also
contributing to the formulae, but I'm very sure that only a select few
actually ever even take look into the internals and supply patches to
this part of the project.

With CMake the situation is more complex. You have three distinct user
groups: (1) People trying to build the software on their machines. They
do not care whether the build system is CMake, SCons, Ant, autohell or
just plain Make. They just want it to work. (2) Developers who use CMake
as their build system of choice and (3) people from the second group who
got annoyed enough by some missing feature or a bug to make the step and
contribute a patch.

Now, the real complication is that CMake must support a large array of
esoteric hardware and operating systems, to which most of the people do
not have access to, or even don't know about, so they can't even take a
guess at potential problems. Also, if you want to get something into
CMake, you have to provide a test and documentation, both of which are
tedious and not very attractive tasks. Also, the CMake code base is
much, much more involved.

There are probably quite a few more issues which make it a lot harder to
contribute to CMake than to Homewbrew.

> 
> I think Github and DVCS really allows you to scale well. If you
> publish decent guidelines for how people can contribute and use e.g.
> pull requests on Github or similar Git mechanisms then you can have
> incredibly quick workflows for viewing, mergeing, testing and pushing
> user code.

That's already there:

http://www.cmake.org/Wiki/CMake/Git
http://public.kitware.com/Wiki/Git/Workflow/Topic

You can also just publish a topic-branch on GitHub and then put a
pull-request in the bug-tracker.

> 
> I have an alias "bpi" in my shell which downloads from a pull request
> or user repository commit on Github, applies it to my local
> repository, shows me the changes and installs the relevant changes
> packages. Once I type "git push" this is now shared with everyone
> using the project.
> 
> I think for you guys general guidelines on what patches would/wouldn't
> be accepted would be a good start. Documentation of your coding
> standards and what I should do to test my work before submitting it
> would help too. I can guess a fair amount because I've contributed to
> a lot of open-source projects but others might not do the same.
> 

I think almost everything that fits into the CMake-picture would get
accepted as long as it meets the quality standards, is documented and
tested. Also, FindXXX.cmake module need a maintainer who commits to
keeping them up-to-date and fixing issues that crop up.

> I think the main thing that I find lacking here though is
> responsiveness to suggestions. When I make one, I need to keep poking
> again and again until I receive I response. Other things include
> specific code review of patches and a quick "this functionality
> would/wouldn't be accepted" when suggestions are made so I know
> whether to work on it or not.

Agreed. Sometimes the response is a bit disappointing. But this probably
also has to do with the fact that one's personal pet-itch isn't as
important to other people as one would like it to be ;-)

> 
> I think using Git/Github in your workflow could help with part of this
> but a certain amount will need to be responding to users, either
> through your current bug tracker, a better one or Github's issue
> tracker.

IMHO Github's issue tracker is far below par. CMake uses Mantis which is
much more powerful, but likely also not to everybody's liking. It
certainly is a bit more complicated to submit a bug report in Mantis
than in the Github tracker.

> 
> Another option that might help is a cmake-dev mailing list that is
> only for discussing development issues rath

Re: [CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 14:30, Bill Hoffman  wrote:
> Something like this perhaps:
>
> http://www.cmake.org/cmake/help/mailing.html
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Excuse my extreme ignorance, I had no idea that existed.
Subscribing!

> 1. you have some code.
>   The biggest thing that slows down adoption of new code in CMake is lack of
> testing.   New features that are not tested, are not welcome into CMake.  If
> the code has a CMake test and there is good dashboard coverage for the test,
> then the code will be adopted much quicker.  The code can be done on github
> or gitorious.org, or just a patch attached to a bug entry in the CMake bug
> tracker.  If a cmake developer can just merge in the code, and run ctest to
> test the new code, it makes it very easy to commit.

Ok, that's good to know. So the basic use-case should be to write the
code, write a test that runs it and ensure it's hooked up to ctest,
make sure it passes and then make a merge request detailing the above.

A few questions:
What platforms does it need to be tested on?
What branch should you base it off?

I wasn't sure if you guys looked at the merge requests on
Github/Gitorious, that's good to know.

> 2. You have a suggestion for a change but no code.
> I think there are two sub-cases for this as well:
>  A. You are willing to write the code yourself.
>  B. You think that someone else should write it for you.
>
> For A, you would want to get buy in from the developers and community before
> starting the code.  For this the cmake-developers mailing list would be the
> place to start.  Although, sometimes it might make sense to float the idea
> on the cmake mailing list first to see what the community things, and then
> use the developers list for implementation details.

Ok, great.

> For B, you have to do a pretty good sales job for the work to be done. You
> are basically asking for a handout.  Kitware does not directly invest in
> CMake, new features developed by Kitware come from Kitware customers
> requesting them.  So, you can hire Kitware (become a customer), or if your
> suggestion lines up with the needs of an existing customer, you might get
> lucky.  Of course Kitware people are not the only ones developing CMake, you
> might be able to convince someone else to do the work.  Either way, this is
> the hardest type of change to have made.

Sure. I'm not in this group as I'm happy to do the work myself but
that's good to know.

> 3. After each release we send out and email to the cmake and
> cmake-developers list, and ask for people to suggest the things they would
> like to see in the next release.  Here is the current list:
> http://public.kitware.com/Bug/roadmap_page.php.  Next release is scheduled
> for Jan. 10.

Cool, again, good to know.

> 4. We have directed all new bugs on the bug tracker to the cmake-developers
> list.  This allows all developers to see new issues as they come in.
>
> 5. We have made an effort to clean up old stuff in the bug tracker.
>
>
> So, if you have time that you want to spend on CMake development, join the
> cmake-developers mailing list.  Write some tested, documented code and
> contribute it.

Great, I think I understand how to do that a bit better now. It would
be great if the contents of your email above was included here:
http://www.cmake.org/cmake/project/getinvolved.html and also possibly
on your Github/Gitorious pages.

Thanks for the comprehensive reply and sorry for any criticism from my
misunderstandings above.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 14:47, Michael Wild  wrote:
> Well, I also did some contributions to homebrew, and I have to agree
> that patches get picked up really quickly. There's one big "but",
> though: Writing a formula is fairly simple. Just copy an existing
> formula that is similar to your favourite package, adapt it, build,
> commit and push. Many contributions are even much simpler: just update
> the version number, done. The learning curve is extremely low. Also,
> Homebrew is Mac-only, so contributors don't have to worry about all the
> exotic platforms out there. They are geeks and nerds who like to build
> stuff themselves. I'd bet that almost everybody using Homebrew is also
> contributing to the formulae, but I'm very sure that only a select few
> actually ever even take look into the internals and supply patches to
> this part of the project.

Yep, good points here, I do agree, I guess I was just trying to be
more specific.


> I think almost everything that fits into the CMake-picture would get
> accepted as long as it meets the quality standards, is documented and
> tested. Also, FindXXX.cmake module need a maintainer who commits to
> keeping them up-to-date and fixing issues that crop up.

Also good to know.

> Agreed. Sometimes the response is a bit disappointing. But this probably
> also has to do with the fact that one's personal pet-itch isn't as
> important to other people as one would like it to be ;-)

Sure, I get that from Homebrew too. I guess my point is that an
apathetic response is better than none at all. I'll use the developers
list for this now though.

> That said, I think it has become much easier to contribute than in CVS
> times. That was just a PITA. But there certainly is room for
> improvement, I agree with that. For one, the Wiki is plain inaccessible.
> E.g. above mentioned CMake/Git Wiki page is completely isolated. Nothing
> links there! Also, the Git/Workflow/Topic page is only reached from (1)
> this isolated CMake/Git page or from the ITK development documentation.
> Then, there is a clear lack of documentation on how to prepare a new
> test. Looking into the existing tests doesn't really help (at least that
> was my impression), as most of the stuff is so convoluted, it takes
> hours to pick apart.

I would agree with this. There's probably a fair amount of wiki
organisation that could be done (which I guess I could help with too)
and some of it could be rolled into the main CMake documentation
perhaps (such as variable descriptions).

I too would love more development/test documentation.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Bill Hoffman]

On 12/23/2010 9:59 AM, Mike McQuaid wrote:


A few questions:
What platforms does it need to be tested on?
At least one.  The important thing is that it actually has a test, that 
will be run with make test on CMake after the code is merged into CMake. 
 The dashboards will take care of testing it on platforms you don't 
have.  We are also working on some interesting stuff in this area as well:


http://www.kitware.com/products/html/TheCDashHomeCloud.html


What branch should you base it off?

master
http://www.cmake.org/Wiki/CMake/Git#Branches

There is also this article that we did on DVCS that might give some 
insight on our thoughts:

http://www.kitware.com/products/html/DistributedVersionControlTheFutureOfHistory.html


Great, I think I understand how to do that a bit better now. It would
be great if the contents of your email above was included here:
http://www.cmake.org/cmake/project/getinvolved.html and also possibly
on your Github/Gitorious pages.

Yes, much of this is new stuff, so it has not yet made it to that page 
yet.  I have been thinking about the issues you brought up for some time 
now, and have not yet written them down.

Thanks for the comprehensive reply and sorry for any criticism from my
misunderstandings above.

Thanks for the post, I am glad that it is more of a "documentation" bug 
than a process issue.  Being on the "inside", I of course know what I 
and the other CMake developers are thinking.  It is easy to fall into 
the trap of thinking that everyone knows what you know...  Although 
sometimes having stuff on web pages is not enough (existence of 
cmake-developers case in point...).   However, the "how to get code into 
CMake" is not documented anywhere yet


Thanks, and I look forward to you contributions!


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[KC Jones]

> Thanks for your comments and questions. May we quote you on that? ("cmake is 
> elegant in the extreme ... great tool")

Of course.  Since all the code I work with is published on multiple OSes, cmake 
is a godsend.  I'm actively working on replacing as much of our legacy build 
methods with cmake solutions.  The cmake basics have come relatively easily to 
me.  CPack is another story.

Once I get through to the end of this tunnel and have learned CPack well 
enough, I hope to be in a position to offer more constructive contributions to 
easing this learning curve.  But, like the problem you describe where there is 
never time for docs and never enough docs, the reality is that when my builds 
are humming, there will be other tasks waiting -- and the task of 'giving back 
to the community' somehow never rises to the top of the stack.

One thought that is jangling around in my head right now:

WRT install(CODE ...) quoting, would it be useful to support the ruby "here 
document" syntax?

install(CODE 

Re: [CMake] CPack 101

[David Cole]

On Thu, Dec 23, 2010 at 3:59 PM, KC Jones  wrote:

> > Thanks for your comments and questions. May we quote you on that? ("cmake
> is elegant in the extreme ... great tool")
>
> Of course.  Since all the code I work with is published on multiple OSes,
> cmake is a godsend.  I'm actively working on replacing as much of our legacy
> build methods with cmake solutions.  The cmake basics have come relatively
> easily to me.  CPack is another story.
>
> Once I get through to the end of this tunnel and have learned CPack well
> enough, I hope to be in a position to offer more constructive contributions
> to easing this learning curve.  But, like the problem you describe where
> there is never time for docs and never enough docs, the reality is that when
> my builds are humming, there will be other tasks waiting -- and the task of
> 'giving back to the community' somehow never rises to the top of the stack.
>
> One thought that is jangling around in my head right now:
>
> WRT install(CODE ...) quoting, would it be useful to support the ruby "here
> document" syntax?
>
> install(CODE fixup_bundle("${APPS}" "${QTPLUGINS}" "${DIRS}")
> xxx
>COMPONENT Runtime)
>
> Or is variable substitution at cmake execution time more the rule than the
> exception?
>
>
I think we've somehow favored install(CODE way too much over install(SCRIPT
in the examples that we *do* have.

If there are serious readability problems with any install(CODE chunk
because of excessive escaping required, it should be in its own file where
it does not need to be escaped, (even if it's only 1, 2 or 3 lines), and
then install(SCRIPT can simply include the file in the very same place where
the CODE would have been generated.

So have a file, InstallBundle.cmake whose contents are:

  include(BundleUtilities)
  fixup_bundle("${APPS}" "${QTPLUGINS}" "${DIRS}")

And then use:

  install(SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/InstallBundle.cmake COMPONENT
Runtime)

Much easier on the eyes, much nicer in every respect except there's one
extra file in your source tree now. Small price to pay for readability and
future maintainability...


HTH,
David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 22:05, David Cole  wrote:
> Much easier on the eyes, much nicer in every respect except there's one
> extra file in your source tree now. Small price to pay for readability and
> future maintainability...

Agreed. I think what would be even nicer would be to be able to do
common tasks using INSTALL(SOMETHING) to e.g. run fixup for you
without having to use another script or INSTALL(CODE).

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack tar ownership

[Tim St. Clair]

Is there a way to make all entries in the tar package are owned by
root, vs. build user.

-- 
Cheers,
Timothy St. Clair
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack and configure_file

[Tobias Ellinghaus]

Hello,

I create some files inside of CMAKE_CURRENT_BINARY_DIR using configure_file(). 
These are not installed but needed for compiling the program. When creating a 
.tgz file with make package_source these files are not included so that the 
resulting source package is basically useless.

Is there a way to add these files? I have searched through google and the list 
archives and only found http://www.cmake.org/Bug/view.php?id=8438 which would 
at least allow to copy the files into CMAKE_CURRENT_SOURCE_DIR.

Thanks
Tobias


signature.asc
Description: This is a digitally signed message part.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack 101

[Alexander Neundorf]

On Thursday 23 December 2010, Mike McQuaid wrote:
...
> > Until then, at least the mailing list has a reasonable response rate and,
> > it seems, sufficient participation from knowledgeable folks willing to
> > pitch in and answer. So... if you're confused about something, please ask
> > here. We (I hope I speak for all CMake devs, here) take no offense. We
> > welcome discussion, always.
>
> The mailing list is OK but most people don't want to sign up to a
> mailing list and receive lots of emails that have nothing to do with
> them. I'm only signed up because I want to try and get some patches
> merged and was told that I should discuss things here rather than the
> bugtracker.
>
> I hope I don't cause any offense here either. I'm passionate about
> CMake because I like the tool and want to make it better.

The cmake wiki is a wiki, you are very welcome to get a login and start 
contributing to the cpack etc. pages :-)

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack, MinGW, strip

[Peter Kümmel]

CMake 2.8.3:

When I install with "mingw32-make install/strip"
the installed files are stripped.

But when I set CPACK_STRIP_FILES to 1 and
use NSIS with "mingw32-make package" the binaries
are not stripped.

CPackConfig.cmake looks correct:

SET(CPACK_BINARY_NSIS "ON")
...
SET(CPACK_CMAKE_GENERATOR "MinGW Makefiles")
...
SET(CPACK_STRIP_FILES "1")


Is this a bug, or is there a simple fix.

Thanks,
Peter
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack and fixup_bundle

[Simon Drouin]

I'm trying to use CPack to create a .tar.gz package on linux. I use
fixup_bundle from the bundle utility to copy and fix Qt libraries to the
bundle.

When I use simple 'make install', everything is installed properly in
directory specified by CMAKE_INSTALL_PREFIX. When I use CPack, the Qt
libraries are still copied to the CMAKE_INSTALL_PREFIX directory and not the
package's directory. Here's the code:

  # install executable(s)

install( TARGETS ${exec_name} DESTINATION . )


 # fixup the bundle

set( APPS ${CMAKE_INSTALL_PREFIX}/${exec_name} )

list( APPEND libSearchDirs ${QT_LIBRARY_DIR})

set( additionalLib ${qtsvgiconplugin} )

INSTALL(CODE "include(BundleUtilities)

fixup_bundle(\"${APPS}\" \"${additionalLib}\"
\"${libSearchDirs}\")" COMPONENT Runtime)


 #

# Packaging

#

set( CPACK_PACKAGE_DESCRIPTION_SUMMARY "My test package")

set( CPACK_PACKAGE_NAME ${exec_name} )

set( CPACK_PACKAGE_CONTACT "John Smith")

set( CPACK_PACKAGE_VENDOR "Company inc.")

set( CPACK_PACKAGE_VERSION_MAJOR ${PROG_MAJOR_VERSION})

set( CPACK_PACKAGE_VERSION_MINOR ${PROG_MINOR_VERSION})

set( CPACK_PACKAGE_VERSION_PATCH ${PROG_PATCH_VERSION})

set( CPACK_GENERATOR "TGZ")

set( CPACK_PACKAGE_FILE_NAME
"${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}-${CMAKE_SYSTEM_PROCESSOR}")

include(CPack)


Am I missing something?


s.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack PackageMaker issue

[Eric Noulard]

Hi all,

Second try to make a package maker package on MacOS using CPack.

Now I am trying to understand why I get a "Bill Of Material" error:
http://www.cmake.org/pipermail/cmake/2011-April/044081.html

Looking at the difference between my pkg and the CMake one
I see  they seems to have the same structure
including Content/Archive.bom and Content/Archive.pax.gz
however in the CMake I can find

Content/Resources/cmake-2.8.4-Darwin-universal.bom which is flagged as
an "alias"
to Content/Archive.bom and in my .pkg there is no bom inside Content/resources

this may be the culprit but "how can I fix that"?
Is the CPack Package Maker author around ?

another difference is the language, my Mac OSX box is "french" so I get
Content/Resource/fr.lproj
instead of
Content/Resousce/English.lproj for CMake installer.

In order to rule out the french/english thing coudl someone tell me
how I can force english/C locale
when building my package ?
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack specify filename

[NoRulez]

Hi,

if I use PackageMaker, DragNDrop, Bundle, OSXX11 then the problem is that all 4 
filenames are equal (e.g. "Project.dmg").
The problem now is, that each cpack routine overwrites the package.

Is it possible to avoid this behavior with a custom filename per Generator?

E.g.: Project_OSXX11.dmg, Project_DragNDrop.dmg, ...

Thanks in advance

Best regards
NoRulez
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack & WiX

[Bill Hoffman]

Tim St. Clair wrote:

I was just wondering if anyone has created a WiX cpack-generator yet,
the wiki says "no", but the wiki is stale and I'm rather surprised
that no one has done it.


No, still not done.

-Bill

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack WiX patch

[Tim St. Clair]

CMake Community -

I've created a patch for CPack to incorporate WiX (to create .msi's),
patch and info can be found @
http://annealingtechnologies.blogspot.com/2010/02/wix-and-cpack-integration.html

I pass the baton for others to push upstream.

-- 
Cheers,
Timothy St. Clair
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack NSIS problem

[Robert Bielik]

I'm trying to get an icon to show in Windows "Programs and features", registry should 
contain a "DisplayIcon" entry pointing to the icon
to show. But CPack generates only:

 ; Optional registration
 Push "DisplayIcon"
 Push "$INSTDIR\"
 Call ConditionalAddToRegisty

which of course will make "Programs and features" show no icon at all. So the question is, how do I tell CPack to create 
a correct path ?


TIA
/Rob
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack PackageMaker Q

[Robert Bielik]

It seems that the CPack PackageMaker generator doesn't (by default) follow the 
guidelines (seemingly important) of PackageMaker, see
f.i. http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html . Is there some 
resource on how to get CPack to do this ?

TIA
/Rob
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack NSIS translation

[Vincent LEFORT]

Hello, i want to use CPack to generate my installer instead of NSIS
directly.

Is it possible to have translation of my installer using CPack/CMake ?

*For example :* At the beginning, NSIS will ask the language of the
installer and after, all the text will be in the selected language.

I don't find anything about this subject and though it's possible with NSIS.

Best regards.

Vincent LEFORT
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack custom page

[Bo Thorsen]

Hi people,

I'm trying to build a custom NSIS page that's shown at the end of the 
installer, after all files have been installed. The purpose is to set up 
a Windows service.


I can do the code for installing the service, but I'm having some 
problems adding the custom page for it. And searching the net haven't 
given me any decent hits. Some pages say I should just hack the template 
file, but that doesn't give any clue what to put in the file.


Can one of you point to example code that adds a custom page, please?

Bo Thorsen.
Monty Program AB.

--

MariaDB: MySQL replacement
Community developed. Feature enhanced. Backward compatible.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack -C

[Bo Thorsen]

Den 01-07-2010 15:39, Bo Thorsen skrev:

When I give an argument to -C, can this be used in the INSTALL commands?


Not possible :( I have added a feature request here:

http://public.kitware.com/Bug/view.php?id=10940

Bo Thorsen.
Monty Program AB.

--

MariaDB: MySQL replacement
Community developed. Feature enhanced. Backward compatible.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack - WiX generator

[Jan Wurster]

 Dear list,

 a couple of months ago someone suggested and implemented a patch for
cmake to add a WiX generator to cpack. 

 http://www.mail-archive.com/cmake@cmake.org/msg26882.html

 The patch is still available
http://annealingtechnologies.blogspot.com/2010/02/wix-and-cpack-integrat
ion.html

 Are there any plans to integrate this code into the official releases? 

 Kind regards and thanks,
Jan 

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack Optional Component

[Vincent LEFORT]

Hello, i use CPack to pack my project.

I use components (cpack_add_component) in it, and i do some links in start
menu using "set(CPACK_NSIS_MENU_LINKS ...)".

But, i want to make the link for example "Documentation" only if the
component "Documentation" is checked.

How i can do this trick ?

Regards.

Vincent
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[Eric Noulard]

2010/8/1 Dennis Schridde :
> Hello!
>
> I just started experimenting with CPack. According to the docs and
> code it is to be used like this:
>> set(CPACK_... ...)
>>
> include(CPack)
>
> This, however, does not allow making use of the defaults
> present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
> I had to
> copy the default value of that variable out of CPack.cmake into my own
> CMakeLists.txt, which does not seem very clean.
>
> Can you add a way of
> configuring CPack that allows appending or modifying default values?
> What
> comes to my mind is a semantic like this:
>> include(CPack)
>> set(CPACK_...
> "${CPACK_...} ...")
>> cpack_config()

I think this is an interesting idea.
May be it's worth a feature request on the tracker:
http://public.kitware.com/Bug/my_view_page.php

This would even be better with a patch proposal :-)

My personal point of view with your idea is that
since we most most probably want to maintain backward compatibility
it would even be better if we can do

1 - set(CPACK_...
2 - include(CPack)
3 - set(CPACK_...)
4 - cpack_update_config() or cpack_reconfig()

that way 1, 3 and 4 are optional just as today.
3 and 4 would bring what you suggest.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[David Cole]

On Sun, Aug 1, 2010 at 6:17 PM, Eric Noulard  wrote:

> 2010/8/1 Dennis Schridde :
> > Hello!
> >
> > I just started experimenting with CPack. According to the docs and
> > code it is to be used like this:
> >> set(CPACK_... ...)
> >>
> > include(CPack)
> >
> > This, however, does not allow making use of the defaults
> > present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
> > I had to
> > copy the default value of that variable out of CPack.cmake into my own
> > CMakeLists.txt, which does not seem very clean.
> >
> > Can you add a way of
> > configuring CPack that allows appending or modifying default values?
> > What
> > comes to my mind is a semantic like this:
> >> include(CPack)
> >> set(CPACK_...
> > "${CPACK_...} ...")
> >> cpack_config()
>
> I think this is an interesting idea.
> May be it's worth a feature request on the tracker:
> http://public.kitware.com/Bug/my_view_page.php
>
> This would even be better with a patch proposal :-)
>
> My personal point of view with your idea is that
> since we most most probably want to maintain backward compatibility
> it would even be better if we can do
>
> 1 - set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 - cpack_update_config() or cpack_reconfig()
>
> that way 1, 3 and 4 are optional just as today.
> 3 and 4 would bring what you suggest.
>


You can already do this today with:

1 - set(CPACK_...
2 - include(CPack)
3 - set(CPACK_...)
4 - include(CPack)

Simply including CPack a second time will configure the files according to
the new values set in step 3. No need for a bug tracker entry, no need to do
any update or re-config. Simply including CPack a second time will call
configure_file for the two files of interest: CPackConfig.cmake and
CPackSourceConfig.cmake...

HTH,
David




>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[Dennis Schridde]

On Monday 02 August 2010 04:03:09 David Cole wrote:
> On Sun, Aug 1, 2010 at
6:17 PM, Eric Noulard  wrote:
>>> [...]
> > My
personal point of view with your idea is that
> > since we most most
probably want to maintain backward compatibility
> > it would even be better
if we can do
> > 
> > 1 - set(CPACK_...
> > 2 - include(CPack)
> > 3 -
set(CPACK_...)
> > 4 - cpack_update_config() or cpack_reconfig()
> > 
> >
that way 1, 3 and 4 are optional just as today.
> > 3 and 4 would bring what
you suggest.
> 
> You can already do this today with:
> 
> 1 -
set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 -
include(CPack)
I tried something similar to this:
# include(CPack)
#
set(CPACK_...)
# include(CPack)
It did not work as expected.

It seems that
when including CPack the 2nd time, things like the version number are not
updated to the new values, probably because the variable is already set and
will not be automatically overwritten.

I assume that you'll suggest "set
the version number before first including CPack". And I will disagree there.
People would have to look at the sourcecode to figure out which values they
have to set before the first inclusion and which to set afterwards. From a
usability point of view this would be bad.

Kind regards,
Dennis


signature.asc
Description: This is a digitally signed message part.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[Eric Noulard]

2010/8/2 David Cole :
> On Sun, Aug 1, 2010 at 6:17 PM, Eric Noulard  wrote:
>>
>> 2010/8/1 Dennis Schridde :
>> > Hello!
>> >
>> > I just started experimenting with CPack. According to the docs and
>> > code it is to be used like this:
>> >> set(CPACK_... ...)
>> >>
>> > include(CPack)
>> >
>> > This, however, does not allow making use of the defaults
>> > present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
>> > I had to
>> > copy the default value of that variable out of CPack.cmake into my own
>> > CMakeLists.txt, which does not seem very clean.
>> >
>> > Can you add a way of
>> > configuring CPack that allows appending or modifying default values?
>> > What
>> > comes to my mind is a semantic like this:
>> >> include(CPack)
>> >> set(CPACK_...
>> > "${CPACK_...} ...")
>> >> cpack_config()
>>
>> I think this is an interesting idea.
>> May be it's worth a feature request on the tracker:
>> http://public.kitware.com/Bug/my_view_page.php
>>
>> This would even be better with a patch proposal :-)
>>
>> My personal point of view with your idea is that
>> since we most most probably want to maintain backward compatibility
>> it would even be better if we can do
>>
>> 1 - set(CPACK_...
>> 2 - include(CPack)
>> 3 - set(CPACK_...)
>> 4 - cpack_update_config() or cpack_reconfig()
>>
>> that way 1, 3 and 4 are optional just as today.
>> 3 and 4 would bring what you suggest.
>
>
> You can already do this today with:
> 1 - set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 - include(CPack)
> Simply including CPack a second time will configure the files according to
> the new values set in step 3. No need for a bug tracker entry, no need to do
> any update or re-config. Simply including CPack a second time will call
> configure_file for the two files of interest: CPackConfig.cmake and
> CPackSourceConfig.cmake...

The second CPack inclusion is not always working as expected
http://public.kitware.com/Bug/view.php?id=10751

most probably because of the "cpack_set_if_not_set" usage inside CPack.cmake

like I said before
set(CPACK_...
include(CPack)

"looks like a function call" but it has several unexpected side effect
because it is not a function call.

To be honest I'm not saying it's not useful as-it-is, it is **not always**
obvious to guess which CPACK_xxx
variables will be taken into account and which won't because of the first
set(CPACK_)


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[Dennis Schridde]

On Monday 02 August 2010 00:17:53 Eric Noulard wrote:
> My personal point of
view with your idea is that
> since we most most probably want to maintain
backward compatibility
> it would even be better if we can do
> 
> 1 -
set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 -
cpack_update_config() or cpack_reconfig()
> 
> that way 1, 3 and 4 are
optional just as today.
> 3 and 4 would bring what you suggest.
Another
option could be:

include(CPack)
cpack_configure(CPACK_... xxx CPACK_... yyy
...)

That way the CPack module would know for sure which values the user
wants to set, and which ones have to be filled with automatic
contents.

This also should not clash with backward compatibility, because
first include(CPack) could setup everything with the dummy values it uses
now.
When cpack_configure is called, it would know exactly what to
overwrite, and where to set default values.


Btw, I think the dummy values
(e.g. version and vendor) CPack.cmake sets atm are not really helpful. They
just cloak any mistakes the user made by forgetting to set some CPACK_...
variable. The values should either be required and empty by default,
generating an error if forgotten. Or they should be constructed from the
other variables with a sensible content.

E.g. I would assume not setting
VERSION_PATCH would make CPack just leave it out, generating a version like
x.y only. But instead it automatically appends a .1 everywhere. Totally not
my intention.
Same goes for vendor=Humanity. I expected I could leave the
variable out for now. Instead of using the empty string (or nothing, it's
really not needed when producing a binary or source tarball) CPack filled it
with some junk.


--Dennis


signature.asc
Description: This is a digitally signed message part.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[David Cole]

On Mon, Aug 2, 2010 at 3:58 AM, Dennis Schridde  wrote:

> On Monday 02 August 2010 04:03:09 David Cole wrote:
> > On Sun, Aug 1, 2010 at
> 6:17 PM, Eric Noulard  wrote:
> >>> [...]
> > > My
> personal point of view with your idea is that
> > > since we most most
> probably want to maintain backward compatibility
> > > it would even be better
> if we can do
> > >
> > > 1 - set(CPACK_...
> > > 2 - include(CPack)
> > > 3 -
> set(CPACK_...)
> > > 4 - cpack_update_config() or cpack_reconfig()
> > >
> > >
> that way 1, 3 and 4 are optional just as today.
> > > 3 and 4 would bring what
> you suggest.
> >
> > You can already do this today with:
> >
> > 1 -
> set(CPACK_...
> > 2 - include(CPack)
> > 3 - set(CPACK_...)
> > 4 -
> include(CPack)
> I tried something similar to this:
> # include(CPack)
> #
> set(CPACK_...)
> # include(CPack)
> It did not work as expected.
>
> It seems that
> when including CPack the 2nd time, things like the version number are not
> updated to the new values, probably because the variable is already set and
> will not be automatically overwritten.
>
> I assume that you'll suggest "set
> the version number before first including CPack". And I will disagree
> there.
> People would have to look at the sourcecode to figure out which values they
> have to set before the first inclusion and which to set afterwards. From a
> usability point of view this would be bad.
>
> Kind regards,
> Dennis
>
>

I stand corrected. Sorry, I thought you just needed CPack's default values
set in order to override some other values based on those defaults. Which
does work, but requires knowledge of which values CPack sets by default
based on which other values...


David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack integration

[Alexander Neundorf]

On Monday 02 August 2010, Eric Noulard wrote:
> 2010/8/1 Dennis Schridde :
> > Hello!
> >
> > I just started experimenting with CPack. According to the docs and
> >
> > code it is to be used like this:
> >> set(CPACK_... ...)
> >
> > include(CPack)
> >
> > This, however, does not allow making use of the defaults
> > present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
> > I had to
> > copy the default value of that variable out of CPack.cmake into my own
> > CMakeLists.txt, which does not seem very clean.
> >
> > Can you add a way of
> > configuring CPack that allows appending or modifying default values?
> > What
> >
> > comes to my mind is a semantic like this:
> >> include(CPack)
> >> set(CPACK_...
> >
> > "${CPACK_...} ...")
> >
> >> cpack_config()
>
> I think this is an interesting idea.
> May be it's worth a feature request on the tracker:
> http://public.kitware.com/Bug/my_view_page.php
>
> This would even be better with a patch proposal :-)
>
> My personal point of view with your idea is that
> since we most most probably want to maintain backward compatibility
> it would even be better if we can do
>
> 1 - set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 - cpack_update_config() or cpack_reconfig()
>
> that way 1, 3 and 4 are optional just as today.
> 3 and 4 would bring what you suggest.


Maybe this should be then more something like:

1 - set(CPACK_...
2 - include(UseCPack)
3 - set(CPACK_...)
4 - cpack_configure()

where UseCPack.cmake would contain just a part of the current CPack.cmake, 
i.e. the part which sets the default values, which would be split out into a 
file shared by both CPack.cmake and UseCPack.cmake, and a macro/function 
which then actually generates the files for cpack.
This way it should be possible to avoid any backwards compatibility issues.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack/nsis behavior

[Clinton Stimpson]

Hi,

I've got this case where I'm using cpack to create nsis packages with a set of 
components that I want packaged.

If I run the installer, things work.
But, if I run the installer a second time (without doing an uninstall first), 
it doesn't do anything.  So, if one had manually removed files, the installer 
doesn't put them back.

I suspect its because there are components, and it assumes it can skip things 
if the component was already installed before (it is saved in the registry 
what components were installed).

Is there a way to force it to install files again?  Much like a repair 
functionality would do?

I tried with the cmake installer, and it installs files again just fine.  I 
suspect that is because there are no components in that installer.

Thanks,
Clint
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Eric Noulard]

2011/9/12 Akshay :
> Hello All,
>
> I have recently ported my project software tree to CMake and I am pretty
> happy about it. There is a last step which is proving quite elusive to me.
> The targets that are built in the software tree are TGZ'd for final
> distribution, however, CPack if run from the CMakeLists.txt file will pickup
> only those targets which are installed by INSTALL command.

This is the expected behavior CPack uses "install".

> I can't change the directory structure for historical reasons. If I use 
> INSTALL from the
> individual directories' CMakeLists.txt, CPack from the main CMakeLists.txt
> is not finding anything and generates an empty TGZ.

How does "make install" behave?
Which version of CMake/CPack are you using?
On which platform?

> src
> |- a
> |- b
> |- c
> |- dt
> |- proj
>    |- CMakeLists.txt (main)
>    |- build
> |- e
>    |- x
>    |- y
>    |- z

This means that you main CMakeLists.txt is in a sibling directory
of others source dir and not has a parent, right?

Would you be able to create a small project which exhibits the same issue?

In particular how do you call CMake in your case?

cd proj/build
cmake ../proj

if so, how do you recurse to other source dirs?
Does your CMakeLists.txt includes something like
add_subdirectory(../a) ?

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Eric Noulard]

2011/9/12 Akshay :
> Hi Eric,

Hi,

Please do not drop the ML address.

> 'make install' puts the targets in the directories that I have set in the
> main CMakeLists.txt.
>I am using CMake 2.8.0 on Ubuntu x64 (Linux valhala
> 2.6.38-10-generic #46~lucid1-Ubuntu SMP Wed Jul 6 18:41:04 UTC 2011 x86_64
> GNU/Linux).

If "make install" is working the way you want there is no reason CPack wouldn't
unless you use absolute install path in your INSTALL command.

> Yes, main CMakeLists.txt is in a sibling directory. Yes, I goto
> the directory of main CMakeLists.txt and do 'cmake CMakeLists.txt' followed
> by 'make'. I have trying all options with the actual source tree.

What do you mean by "all options"?

> However
> before starting, I used a single level dummy project where things worked
> fine. I have used INCLUDE_SUBDIRECTORY() for all the source directories with
> relative paths.

INCLUDE_SUBDIRECTORY is not a CMake command you must be using
ADD_SUBDIRECTORY.

Could you send us your main CMakeLists.txt and an example of CMakeLists.txt
you use in one subdir.

Or better build self-contained dummy project which exhibit the issue.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Akshay]

Hi Eric,

Just to clarify, INSTALL command are present in the sibling source
directories' CMakeLists.txt and not in the main CMakeLists.txt. Would this
change the behavior of CPack (which is present only in the main
CMakeLists.txt) ?

Akshay


On Mon, Sep 12, 2011 at 12:18 PM, Eric Noulard wrote:

> 2011/9/12 Akshay :
> > Hi Eric,
>
> Hi,
>
> Please do not drop the ML address.
>
> > 'make install' puts the targets in the directories that I have set in the
> > main CMakeLists.txt.
> >I am using CMake 2.8.0 on Ubuntu x64 (Linux valhala
> > 2.6.38-10-generic #46~lucid1-Ubuntu SMP Wed Jul 6 18:41:04 UTC 2011
> x86_64
> > GNU/Linux).
>
> If "make install" is working the way you want there is no reason CPack
> wouldn't
> unless you use absolute install path in your INSTALL command.
>
> > Yes, main CMakeLists.txt is in a sibling directory. Yes, I goto
> > the directory of main CMakeLists.txt and do 'cmake CMakeLists.txt'
> followed
> > by 'make'. I have trying all options with the actual source tree.
>
> What do you mean by "all options"?
>
> > However
> > before starting, I used a single level dummy project where things worked
> > fine. I have used INCLUDE_SUBDIRECTORY() for all the source directories
> with
> > relative paths.
>
> INCLUDE_SUBDIRECTORY is not a CMake command you must be using
> ADD_SUBDIRECTORY.
>
> Could you send us your main CMakeLists.txt and an example of CMakeLists.txt
> you use in one subdir.
>
> Or better build self-contained dummy project which exhibit the issue.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Eric Noulard]

2011/9/12 Akshay :
> Hi Eric,
>
> Just to clarify, INSTALL command are present in the sibling source
> directories' CMakeLists.txt and not in the main CMakeLists.txt. Would this
> change the behavior of CPack (which is present only in the main
> CMakeLists.txt) ?

No it shouldn't.
Provided that:

add_subdirectory comes before include(CPack) in the main CMakeLists.txt
and
install command do not use absolute install path.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Akshay]

I'll try and get back. Thanks very much for the help.

Akshay


On Mon, Sep 12, 2011 at 12:34 PM, Eric Noulard wrote:

> 2011/9/12 Akshay :
> > Hi Eric,
> >
> > Just to clarify, INSTALL command are present in the sibling source
> > directories' CMakeLists.txt and not in the main CMakeLists.txt. Would
> this
> > change the behavior of CPack (which is present only in the main
> > CMakeLists.txt) ?
>
> No it shouldn't.
> Provided that:
>
> add_subdirectory comes before include(CPack) in the main CMakeLists.txt
> and
> install command do not use absolute install path.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack question.

[Akshay]

Thanks Eric. Everything working now. I was using absolute paths in INSTALL
commands.

Akshay


On Mon, Sep 12, 2011 at 12:36 PM, Akshay  wrote:

> I'll try and get back. Thanks very much for the help.
>
> Akshay
>
>
>
> On Mon, Sep 12, 2011 at 12:34 PM, Eric Noulard wrote:
>
>> 2011/9/12 Akshay :
>> > Hi Eric,
>> >
>> > Just to clarify, INSTALL command are present in the sibling source
>> > directories' CMakeLists.txt and not in the main CMakeLists.txt. Would
>> this
>> > change the behavior of CPack (which is present only in the main
>> > CMakeLists.txt) ?
>>
>> No it shouldn't.
>> Provided that:
>>
>> add_subdirectory comes before include(CPack) in the main CMakeLists.txt
>> and
>> install command do not use absolute install path.
>>
>> --
>> Erk
>> Membre de l'April - « promouvoir et défendre le logiciel libre » -
>> http://www.april.org
>>
>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack problem

[Eric Noulard]

2011/10/27  :
> Hello,
>
> I've built an installer using cmake / cpack / nsis. I work under windpws XP 
> 64 bits.
> I first built a "monolithic" installer and everything is fine. My installer 
> have several components.
> Now, I build a "network" installation. So, I added:
>
>  cpack_configure_downloads(ftp://ftp.myftpsite.fr/New
>                            ALL)
>
> I have installed the nsis plugin ZipDLL in the right place.
> The installer builds nicely. I uploaded all the zipped component on my ftp 
> site and now, if I execute the installer, all the selected components are 
> correctly installed but:
> - all the files are hidden ...

What do you mean by "hidden" ?
They do have the "hidden" attribute set?
Sorry for the dummy question but I'm not using Windows very often so I
wonder what this mean?

Could you narrow down the problem a little bit.
Does a component installer WITHOUT  ZipDLL and
cpack_configure_downloads works ok?
i.e. no hidden files?
You said that "monolithic" installer works, it monolithic in the CPack
sense (no component)
or in the sense that you do not get files from the network?

> - another problem, two components have a file in common. ZipDLL doesn't like 
> this and an error message is displayed. I needed to add another component to 
> store the common files, and add a dependency in the cmakelists.txt file.

This one looks like a ZipDLL/NSIS problem.
>From reading zipdll.nsh, It looks like "ZIPDLL_EXTRACT" NSIS macro
is checking if file/directory exists before extracting.

May be you can customize that in order to avoid the check,
however silent overwrite has its drawback as well.

Third dependent component seems the safest option.

> Does somebody had the same problem (all installed files are hidden) ?

not me, but I'm not using CPack on Windows very often.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack problem

[ycollette . nospam]

> What do you mean by "hidden" ?
> They do have the "hidden" attribute set?

Yes, all the files have the hidden attribute.


> Does a component installer WITHOUT  ZipDLL and cpack_configure_downloads 
> works ok?

Yes, that's what I wanted to say by "monolithic" install works fine.

> This one looks like a ZipDLL/NSIS problem.
> From reading zipdll.nsh, It looks like "ZIPDLL_EXTRACT" NSIS macro is 
> checking if file/directory exists before extracting.

This is certainly a ZipDLL problem. All the installed files have the hidden AND 
write protected attribute.

> Third dependent component seems the safest option.

I already build components with common files inside. Just remain the problem of 
hidden and write protected attributes.

Thanks for your answers.

YC
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack NSIS RequestExecutionLevel

[rpf]

Hi everyone,

I am compiling an installer for Windows 7 using CPack + NSIS.
I need to pass the extra option

RequestExecutionLevel user

to NSIS. Does anyone know how to do this? The only way proposed somewhere on 
the net was to use

set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "RequestExecutionLevel user")

but that raises an error in NSIS (Error: command RequestExecutionLevel not 
valid in Section).

Any help is greatly appreciated

Hans
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack -G NSIS

[Andrea Crotti]

Trying to run cpack on Linux (archlinux 64 bit) with a working makensis 
environment,

I get the following error (and following stacktrace):

[andrea@precision test_cmake]$ gdb cpack
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/cpack...(no debugging symbols found)...done.
(gdb) run -G NSIS
Starting program: /usr/bin/cpack -G NSIS
[Thread debugging using libthread_db enabled]
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

Program received signal SIGABRT, Aborted.
0x76c90935 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x76c90935 in raise () from /lib/libc.so.6
#1  0x76c91dab in abort () from /lib/libc.so.6
#2  0x772d11ed in __gnu_cxx::__verbose_terminate_handler() () 
from /usr/lib/libstdc++.so.6

#3  0x772cf396 in ?? () from /usr/lib/libstdc++.so.6
#4  0x772cf3c3 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0x772cf4be in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0x7727c1f7 in std::__throw_logic_error(char const*) () from 
/usr/lib/libstdc++.so.6
#7  0x772ba039 in char* std::string::_S_constructconst*>(char const*, char const*, std::allocator const&, 
std::forward_iterator_tag) () from /usr/lib/libstdc++.so.6
#8  0x772ba113 in std::basic_stringstd::char_traits, std::allocator >::basic_string(char 
const*, std::allocator const&) () from /usr/lib/libstdc++.so.6

#9  0x0048a9f6 in cmCPackNSISGenerator::InitializeInternal() ()
#10 0x0047b784 in cmCPackGenerator::Initialize(char const*, 
cmMakefile*) ()

#11 0x00474562 in main ()


Any idea about what it could be?
Thanks,
Andrea
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack issues

[David Cole]

Use:

  DESTINATION ${PROJECT_NAME}

instead of the full path you're trying to use.

If you use a full path in a CMake install rule, then CPack does not put it
inside the directory that NSIS packs up to build the installer... If you
use a non-full path, then for "make install" it gets put under
CMAKE_INSTALL_PREFIX, and for the CPack-based install, it gets put in the
directory that NSIS packs up...


HTH,
David


On Tue, Feb 21, 2012 at 12:40 PM, Andrea Crotti
wrote:

> I'm trying to finally create an installer for my project, with CPack and
> NSIS.
>
> The project is really really simple, I just need to copy over a directory
> somewhere.
> And I did something like:
>
> get_filename_component(**userprofile $ENV{USERPROFILE} REALPATH)
>
> install(
>  DIRECTORY ${EGG_BUILD_DIRECTORY}
>  DESTINATION ${userprofile}/${PROJECT_NAME}
>  )
>
>
> The first line is because CPack was exploding using the USERPROFILE,
> because
> it was getting non quoted backslash.
>
> So is it the way to handle windows path variables?
>
> The packing, however, doesn't work and I get something like (from the NSIS
> generated log file):
>
> !insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
> Section: "-Core installation"
> SetOutPath: "$INSTDIR"
> File: Returning to: "H:/long_path/_CPack_Packages/**win32/NSIS/Minimum
> Drag-0.1.1-win32"
> File: "H:/long_path/_CPack_Packages/**win32/NSIS/Minimum
> Drag-0.1.1-win32\*.*" -> no files found.
> Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
>   /oname=outfile one_file_only)
> Error in script "H:/git_projs/Minimum_Drag/**airbus.application.minimum_**
> drag/_CPack_Packages/win32/**NSIS/project.nsi" on line 640 -- aborting
> creation process
>
> These are the variables that I defined
> set(CPACK_NSIS_INSTALLED_ICON_**NAME "${PROJECT_NAME}")
> set(CPACK_PACKAGE_ICON "Company")
> set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
>
> set(CPACK_RESOURCE_FILE_**LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/**
> COPYRIGHT.txt")
> set(CPACK_PACKAGE_VERSION_**MAJOR 0)
> set(CPACK_PACKAGE_VERSION_**MINOR 1)
> set(CPACK_CREATE_DESKTOP_LINKS "${PROJECT_NAME}")
> set(CPACK_PACKAGE_INSTALL_**DIRECTORY "${PROJECT_NAME}") # add the
> version numbers
> set(CPACK_PACKAGE_DESCRIPTION "Package ${PROJECT_NAME}")
>
>
> is there anything missing?
> Any idea what that could be?
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack issues

[Eric Noulard]

2012/2/21 Andrea Crotti :
> I'm trying to finally create an installer for my project, with CPack and
> NSIS.
>
> The project is really really simple, I just need to copy over a directory
> somewhere.
> And I did something like:
>
> get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
>
> install(
>  DIRECTORY ${EGG_BUILD_DIRECTORY}
>  DESTINATION ${userprofile}/${PROJECT_NAME}
>  )

Is "userprofile" an absolute path? (sorry I'm not working on Windows very often)
if this is the case this will not work.

DO NEVER install with absolute install path on Windows:
   1) the installed pieces won't be put in the installer
   2) the files/dirs/whatever MAY (if you have enough privilege) be
installed on the machine
   on which you are trying to build the package!!

I think we should forcibly forbid absolute install path on
windows...but that's another story.

> The first line is because CPack was exploding using the USERPROFILE, because
> it was getting non quoted backslash.
>
> So is it the way to handle windows path variables?

Usually you go from to native path representation using

file(TO_NATIVE_PATH path result)
file(TO_CMAKE_PATH path result)

see:
cmake --help-command file

> The packing, however, doesn't work and I get something like (from the NSIS
> generated log file):
>
> !insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
> Section: "-Core installation"
> SetOutPath: "$INSTDIR"
> File: Returning to: "H:/long_path/_CPack_Packages/win32/NSIS/Minimum
> Drag-0.1.1-win32"
> File: "H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*"
> -> no files found.
> Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
>   /oname=outfile one_file_only)
> Error in script
> "H:/git_projs/Minimum_Drag/airbus.application.minimum_drag/_CPack_Packages/win32/NSIS/project.nsi"
> on line 640 -- aborting creation process
>
> These are the variables that I defined
> set(CPACK_NSIS_INSTALLED_ICON_NAME "${PROJECT_NAME}")

this one looks wrong:
CPACK_NSIS_INSTALLED_ICON_NAME
   A path to the executable that contains the installer icon.

> set(CPACK_PACKAGE_ICON "Company")

same for this one:
CPACK_PACKAGE_ICON
   A branding image that will be displayed inside the installer.

the documentation currently found  in CPack.cmake
or http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS
(and soon from cpack --help-variable)
could be improved but both the previous variables should refer to files.

> set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
>
> set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/COPYRIGHT.txt")
> set(CPACK_PACKAGE_VERSION_MAJOR 0)
> set(CPACK_PACKAGE_VERSION_MINOR 1)
> set(CPACK_CREATE_DESKTOP_LINKS "${PROJECT_NAME}")

I think this one refers to a executable installed by the project.
(but there is not documentation [yet] for "CPACK_CREATE_DESKTOP_LINKS" :-]

> set(CPACK_PACKAGE_INSTALL_DIRECTORY "${PROJECT_NAME}") # add the version
> numbers
> set(CPACK_PACKAGE_DESCRIPTION "Package ${PROJECT_NAME}")

there is no such variable.
There is:
CPACK_PACKAGE_DESCRIPTION_SUMMARY
   Short description of the project (only a few words).
CPACK_PACKAGE_DESCRIPTION_FILE
   A text file used to describe the project.

   Used, for example, the introduction screen of a CPack-generated
   Windows installer to describe the project.

> is there anything missing?
> Any idea what that could be?

A lot of things...
first did have a look at the error:
"H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*"

is it true?

then open the project.nsi file and try to fix things "by hand".
then go back to your


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack issues

[Andrea Crotti]

On 02/21/2012 06:25 PM, Eric Noulard wrote:

2012/2/21 Andrea Crotti:

I'm trying to finally create an installer for my project, with CPack and
NSIS.

The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:

get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)

install(
  DIRECTORY ${EGG_BUILD_DIRECTORY}
  DESTINATION ${userprofile}/${PROJECT_NAME}
  )

Is "userprofile" an absolute path? (sorry I'm not working on Windows very often)
if this is the case this will not work.

DO NEVER install with absolute install path on Windows:
1) the installed pieces won't be put in the installer
2) the files/dirs/whatever MAY (if you have enough privilege) be
installed on the machine
on which you are trying to build the package!!

I think we should forcibly forbid absolute install path on
windows...but that's another story.


I see, well I just wanted to get something running quickly to see if the 
packaging actually works.
Anyway my assumption was that $ENV{USERPROFILE} would be the userprofile 
directory on the machine
where I will run the installer, but I understand now why this is a very 
stupid assumption.


With the relative path I got an actual installer in the end, but I get 
another error when I try to run it

that I will investigate further tomorrow..
Thanks a lot for now.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack issues

[Andrea Crotti]

Alright then I now actually get an installer which I can click on, and 
cpack doesn't give any more errors.


However, when I try to run the executable I get a
"executable..exe The specified path does not exist.."

which is quite a weird error, because it's the same path that I'm 
clicking, and it does exists :S


Has anyone seen this?
I just changed the destination to the ${PROJECT_NAME}:
install(
  DIRECTORY ${EGG_BUILD_DIRECTORY}
  DESTINATION ${PROJECT_NAME}
  )

but in general, how would I make sure that the final installer will try 
to install the software

in $ENV{USERPROFILE} for example?

Writing it in the destination is clearly wrong, but is there another way 
then?


Thanks,
Andrea
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack : WM_SETTINGCHANGE broadcast

[Nicholas Yue]

Hi,

I understand from reading the following article

http://support.microsoft.com/kb/104011 



that one need to broadcast a WM_SETTINGSCHANGE for environment 
variable updated via the registry key to take effect in the current session


I have been able to update the registry and re-login in have the 
effect of updating the environment, using the information from the 
following URL


http://nsis.sourceforge.net/Docs/Chapter4.html 



However, I was unable to determine a way from within CPack to do a 
WM_SETTINGSCHANGE broadcast so that the user installing the software I 
am packaging not to have to log-out and log-in for the updated 
environment variable to take effect.


Is there a different approach ?

Regards

--
Nicholas Yue
Graphics - RenderMan, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
Management - Recruitment, career management
http://www.proceduralinsight.com/
http://au.linkedin.com/in/nicholasyue


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack install directory

[Raphael Cotty]

Hi,
I am using CPack with DEB generator. My install dir is in
/work/install/Project and I have a usr and a etc dir installed.
But the debian package generated by CPack inserts a usr directory so I get
my usr in usr/usr and my etc in /usr/etc.
I don't manage to understand why and where is inserted this directory.
Any idea how I could remove it?

Thanks very much!
Raph

ps:
I am using cmake and cpack version 2.5-20071214.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack install directory

[Raphael Cotty]

Hi,
After looking at the source code I found in CPack/cmCPackDebGenerator.cxx
that if CPACK_PACKAGING_INSTALL_PREFIX is not set then it is set to "/usr".
Then the data.tar.gz is creating from directory usr.
First this code will give an understandable error if the user sets
CPACK_PACKAGING_INSTALL_PREFIX to something else than "/usr".
Secondly this doesn't allow the debian package to install files anywhere.

This insertion of a usr directory is done I suppose to allow the tar command
not to add the control, debian-binary, and itself.
One way to get ride of this is to remove the "usr" insertion, do the tar
first like this: (tar cfz ../data.tar.gz .), copy it to the current
directory, remove it from the previous location. Then do the rest of the
work like before.
This of course can be optimised.

This way actually works for me. Is there any other reason to do the
insertion of the usr directory?

Raphael
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack : seg fault

[Mathieu Malaterre]

Hi,

  I am getting a seg fault somewhere in CPack (CVS HEAD and cmake
2.4.7) on cygwin, but even with a debug build of CMake I cannot get a
nice backtrace (*). Has anyone any suggestion on how to deubg this
thing ?

Thanks
-Mathieu

Run CPack packaging tool...
/home/mmalaterre/Projects/CMake-cyg/bin/cpack.exe --config /home/mmalaterre/Proj
ects/gdcm/trunk/cygwin/CPackConfig.cmake
CPack: Create package using CygwinBinary
 24 [main] cpack 5096 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
make: *** [package] Segmentation fault (vidange mémoire)

[EMAIL PROTECTED] ~/Projects/gdcm/trunk/cygwin
$ gdb /home/mmalaterre/Projects/CMake-cyg/bin/cpack.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r --config /home/mmalaterre/Projects/gdcm/trunk/cygwin/CPackConfig.cmake

Starting program: /home/mmalaterre/Projects/CMake-cyg/bin/cpack.exe --config /ho
me/mmalaterre/Projects/gdcm/trunk/cygwin/CPackConfig.cmake
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll
CPack: Create package using CygwinBinary
 15 [main] cpack 5856 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V
IOLATION
607 [main] cpack 5856 open_stackdumpfile: Dumping stack trace to cpack.exe.s
tackdump
1482308 [main] cpack 5856 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_V
IOLATION
1504326 [main] cpack 5856 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)

Program received signal SIGSEGV, Segmentation fault.
0x610164e5 in stack_info::walk () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x610164e5 in stack_info::walk () from /usr/bin/cygwin1.dll
#1  0x7c859dcc in OutputDebugStringA ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#2  0x40010006 in ?? ()
#3  0x in ?? ()
(gdb)

-- 
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack OSX Bundles

[Timothy M. Shead]

Folks:

I'm generating OSX bundles for a couple of projects with GTK and one
with Qt dependencies.  Currently I handle everything with CMake, custom
targets, and some custom shell scripts, but I'd like to get CPack to do
the work.  

The OSXX11 generator is *almost* perfect, but I need some additional
flexibility.  Basically, I'd like to provide my own replacements for the
script-launcher in Contents/MacOS and the
Contents/Resources/RuntimeScript startup script - this is to setup a
custom environment for the GTK libs and specify some command-line
arguments for my executables.  In the Qt case, I don't need to start X11
at all, so the startup script could be considerably simplified.

Would there be any interest in a patch for the OSXX11 generator along
these lines?  Would an entirely new generator be better?

Cheers,
Tim


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack OSX Bundles

[Timothy M. Shead]

> Folks:
> 
> I'm generating OSX bundles for a couple of projects with GTK and one
> with Qt dependencies.  Currently I handle everything with CMake,
> custom
> targets, and some custom shell scripts, but I'd like to get CPack to
> do
> the work.  
> 
> The OSXX11 generator is *almost* perfect, but I need some additional
> flexibility.  Basically, I'd like to provide my own replacements for
> the
> script-launcher in Contents/MacOS and the
> Contents/Resources/RuntimeScript startup script - this is to setup a
> custom environment for the GTK libs and specify some command-line
> arguments for my executables.  In the Qt case, I don't need to start
> X11
> at all, so the startup script could be considerably simplified.
> 
> Would there be any interest in a patch for the OSXX11 generator along
> these lines?  Would an entirely new generator be better?
> 
> Cheers,
> Tim

I'm a little surprised at the lack of feedback ... is this a lousy idea?
Are there existing alternatives?  I'm anxious to contribute, but I don't
want to waste my time if there's no interest ...

Many thanks,
Tim


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [CPACK] debian package

[Mathieu Malaterre]

Hi,

  Please consider the attached patch for inclusion in cmake 2.6.0.
Without the patch it puts the responsability on each packager to
properly set the architecture to create valid debian package. Instead
getting the result from dpkg --print-architecture is the correct way.

Right now I have to do:

  IF(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64")
SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE amd64)
  ELSEIF(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "i686")
SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE i386)
  ENDIF(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64")


  The initial plan was not to rely on any tool to create debian
package, but since NSIS packager rely on NSIS exe, I believe relying
on the presence of dpkg is relatively weak.

Thanks

-- 
Mathieu
Index: Modules/CPackDeb.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/CPackDeb.cmake,v
retrieving revision 1.8
diff -u -r1.8 CPackDeb.cmake
--- Modules/CPackDeb.cmake	17 Jan 2008 22:19:13 -	1.8
+++ Modules/CPackDeb.cmake	28 Mar 2008 15:31:03 -
@@ -34,14 +34,14 @@
 
 # Architecture: (mandatory)
 IF(NOT CPACK_DEBIAN_PACKAGE_ARCHITECTURE)
-# There is no such thing as i686 architecture on debian, you should use i386 instead
-# $ dpkg --print-architecture
-  SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE i386)
+  EXEC_PROGRAM(dpkg ARGS --print-architecture OUTPUT_VARIABLE CPACK_DEBIAN_PACKAGE_ARCHITECTURE)
 ENDIF(NOT CPACK_DEBIAN_PACKAGE_ARCHITECTURE)
 
 # have a look at GET_PROPERTY(result GLOBAL PROPERTY ENABLED_FEATURES),
 # this returns the successful FIND_PACKAGE() calls, maybe this can help
 # Depends:
+# You should set: DEBIAN_PACKAGE_DEPENDS
+# TODO: automate 'objdump -p | grep NEEDED'
 IF(NOT CPACK_DEBIAN_PACKAGE_DEPENDS)
   MESSAGE(STATUS "CPACK_DEBIAN_PACKAGE_DEPENDS not set, the package will have no dependencies.")
 ENDIF(NOT CPACK_DEBIAN_PACKAGE_DEPENDS)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake-CPack-NSIS

[Alin M Elena]

Hi,

 

 I want to setup a variable(TestVar) on windows when I use NSIS
using cmake/cpack.

A small example is presented here

   http://nsis.sourceforge.net/Setting_Environment_Variables

 

   The idea is that the project.nsi which is created by cmake already sets a
variable PATH.

   Can I reuse some of the functions already defined there?

 

  I suspect that everything should be added using
CPACK_NSIS_EXTRA_(UN)INSTALL_COMMANDS

  I see the plural form of the commands. Can you pass more commands? How do
you separate them?

 

 

Alin

 

 

 

 

 

 



"...if the universities will not study useless subjects, who will?"

   G. F. Fitzgerald, Nature, 45/46, 392 (1892)

__

Mr. Alin M. ELENA

Atomistic Simulation Centre

School of Mathematics and Physics

Queen's University Belfast

Office: +44 (0)28 9097 1428

Fax: +44 (0)28 9097 5359

http://titus.phy.qub.ac.uk/group/Alin/

[EMAIL PROTECTED]

[EMAIL PROTECTED]

__

 

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake/CPack/NSIS

[Alin M Elena]

Hi,

I try to package a project with CMake/CPack/NSIS

I have to "aesthetic" problems with it

1. The icon for the binary does not get set.
2. The shortcut on the desktop does not get created.
In the attach is the CMakeLists.txt that I use.

Any Ideas?

Alin





"...if the universities will not study useless subjects, who will?"
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED]
[EMAIL PROTECTED]
__


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake