Notes
(0035846) Nils Gladitz (developer) 2014-05-09 09:13	This is currently not possible. I don't think this is something supported by any of the other installer generators so there is probably no existing feature I could map this to. Perhaps I could extend the patch schema to allow attribute definitions. e.g. <CPackWiXAttribute name="NeverOverwrite" value="yes"/> as direct children of a <CPackWiXFragment>. I am not entirely sure how to handle conflicts in case the generator itself uses the same attribute though (now or in the future). Both ignoring and failing on such a conflict might break an installer. Any ideas/opinions?

(0035849) Richard Ulrich (reporter) 2014-05-12 03:55	Yes the approach with direct attributes sounds good. I would say the attributes from the patch file have precedence. Don't prioritize it too high though. In my specific case, I would need to loop through the source directory anyway to generate the patch file. So, I can just as well exclude these special directories from the INSTALL target, and generate a *.wxs file for inclusion myself. Unless, there ways a way to specify such attributes to apply to file components that match a certain regex. But that would probably go too far...

(0035876) Richard Ulrich (reporter) 2014-05-14 05:46	For the meantime I solved it with a console app that generates a wxi file containing the components with the special attributes for these files. And I excluded these special folders form the cmake install targets. It does work, but it's not really elegant. So, I thought it would be possible to use CPACK_WIX_PATCH_FILE for that if: * your suggestion with direct attributes was implemented * and the component names of the patch file supported wildcards. Then I could simply write : <CPackWiXPatch> <CPackWiXFragment Id=".__userconfig__."> <CPackWiXAttribute name="NeverOverwrite" value="yes"/> </CPackWiXFragment> </CPackWiXPatch> What do you think about that?

(0035878) Nils Gladitz (developer) 2014-05-14 07:58	Support of wildcards I'd put into a distinct feature request. I currently track consumption of patch fragments to make sure they all get applied exactly once. This is intended to prevent silent failures due to e.g. typos, renames or moved files. Use of wildcards would contradict this somewhat. Also long identifiers are replaced by hashed ids which might not match the wildcards that were intended for them. What would be nice is if the existing property system could be extended to installed files somehow. I could then establish e.g. a NEVER_OVERWRITE property which you could apply to the files for which it is intended and query it in the WIX generator.

(0035898) Nils Gladitz (developer) 2014-05-17 06:04	I've got a preliminary implementation (implementation and interface are subject to change) for CPack properties in general and NEVER_OVERWRITE and PERMANENT for the WIX generator specifically: https://github.com/ngladitz/cmake/tree/cpack-properties [^] I've got an example of them being used here: https://github.com/ngladitz/cmake-wix-testsuite/blob/master/properties/CMakeLists.txt [^] Do you think this would cover your use case?

(0035902) Richard Ulrich (reporter) 2014-05-21 11:10	Wow, your implementing faster than I can test. It looks promising, but it's not quite working for me yet. FILE(GLOB FILES_IN_USERCONF PointLineParamLib/module/mod/${SubDirName}/_userconfig_/.) FILE(GLOB FILES_IN_USERLIB PointLineParamLib/module/mod/${SubDirName}/_userconfig_/.) SET_PROPERTY(INSTALL ${FILES_IN_USERCONF} ${FILES_IN_USERLIB} PROPERTY CPACK_NEVER_OVERWRITE ON) SET_PROPERTY(INSTALL ${FILES_IN_USERCONF} ${FILES_IN_USERLIB} PROPERTY CPACK_PERMANENT ON) gives me : CMake Error at CMakeLists.txt:117 (SET_PROPERTY): set_property given invalid scope INSTALL. Valid scopes are GLOBAL, DIRECTORY, TARGET, SOURCE, TEST, CACHE, CPACK. so, I changed it to : FILE(GLOB FILES_IN_USERCONF PointLineParamLib/module/mod/${SubDirName}/_userconfig_/.) FILE(GLOB FILES_IN_USERLIB PointLineParamLib/module/mod/${SubDirName}/_userconfig_/.) SET_PROPERTY(CPACK ${FILES_IN_USERCONF} ${FILES_IN_USERLIB} PROPERTY CPACK_NEVER_OVERWRITE ON) SET_PROPERTY(CPACK ${FILES_IN_USERCONF} ${FILES_IN_USERLIB} PROPERTY CPACK_PERMANENT ON) It looks correct in build/CPackProperties.cmake, but in _CPack_Packages\win32\WIX\files.wxs they are not reflected on the Component tags. So, I figured, in cmWIXFilesSourceWriter::EmitComponentFile() it should probably read : if(installedFile->GetPropertyAsBool("CPACK_NEVER_OVERWRITE")) { AddAttribute("NeverOverwrite", "yes"); } if(installedFile->GetPropertyAsBool("CPACK_PERMANENT")) { AddAttribute("Permanent", "yes"); } But the code was not hit, because in cmake::GetOrCreateInstalledFile() a relative path is searched in a map with absolute path names. This is where I don't know how such things are usually handled in cmake. Just passing fullPath to GetInstalledFile() didn't work out, as that's the path in the temporary WiX install dir, while in the map it's the source path.

(0035903) Nils Gladitz (developer) 2014-05-21 11:36	I had to change the implementation to mach some new requirements. I assume you checked out the implementation before I did those changes but took the example code after I updated it. The name of the scope was changed from CPACK to INSTALL and the two properties each got a CPACK_ prefix. Sorry for the mixup ... I should have put up a note here. In case you are interested the current discussion on the topic is here: http://public.kitware.com/pipermail/cmake-developers/2014-May/010452.html [^] Your GLOB is returning the absolute paths. Try using RELATIVE to have it return paths relative to the destination prefix.

(0035904) Richard Ulrich (reporter) 2014-05-22 03:45	You're right, after pulling the latest code from github, and using relative paths in my file glob command, it works perfectly fine. Many thanks for implementing this so fast. When will this be in the official release of cmake? What is your BitCoin address to buy you a beer? Now that this works so well, here comes my next requirement: File permissions. I created a new issue for that : http://public.kitware.com/Bug/view.php?id=14924 [^]

(0035906) Nils Gladitz (developer) 2014-05-22 04:05	Thanks for testing! I still have to implement genex support for keys and values which I hope to get done this weekend. Assuming there are no problems and the topic gets accepted and merged it should get into 3.1. 3.1 (according to the tracker) is scheduled for 2014-06-01 but I assume that will be delayed given that 3.0 is still pending.

(0035956) Nils Gladitz (developer) 2014-05-28 15:11	The topic has been merged to master: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;hp=032961c6ac81d82270a7b1986935111aa5e32a56;h=d0b1d2a65be658663ce7314961e13036974f62e7 [^]

(0037146) Robert Maynard (manager) 2014-11-03 08:38	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2014-05-09 06:37	Richard Ulrich	New Issue
2014-05-09 06:47	Nils Gladitz	Assigned To	=> Nils Gladitz
2014-05-09 06:47	Nils Gladitz	Status	new => assigned
2014-05-09 09:13	Nils Gladitz	Note Added: 0035846
2014-05-12 03:55	Richard Ulrich	Note Added: 0035849
2014-05-14 05:46	Richard Ulrich	Note Added: 0035876
2014-05-14 07:58	Nils Gladitz	Note Added: 0035878
2014-05-17 06:04	Nils Gladitz	Note Added: 0035898
2014-05-21 11:10	Richard Ulrich	Note Added: 0035902
2014-05-21 11:36	Nils Gladitz	Note Added: 0035903
2014-05-22 03:45	Richard Ulrich	Note Added: 0035904
2014-05-22 04:05	Nils Gladitz	Note Added: 0035906
2014-05-28 15:11	Nils Gladitz	Note Added: 0035956
2014-05-28 15:11	Nils Gladitz	Status	assigned => resolved
2014-05-28 15:11	Nils Gladitz	Fixed in Version	=> CMake 3.1
2014-05-28 15:11	Nils Gladitz	Resolution	open => fixed
2014-11-03 08:38	Robert Maynard	Note Added: 0037146
2014-11-03 08:38	Robert Maynard	Status	resolved => closed

Relationships