Re: [CMake] Implicity CMAKE_CURRENT_BINARY_DIR include_directories
On Saturday 09 May 2009 22:25:24 Alexander Neundorf wrote: > > set(CMAKE_INCLUDE_CURRENT_DIR ON) > Documentation committed to HEAD. Cheers Alex, I was sure I'd seen it somewhere! -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Implicity CMAKE_CURRENT_BINARY_DIR include_directories
I'm sure I read some time about some option you could set in a CMake project
that would always implicitly do
include_directories(${CMAKE_CURRENT_BINARY_DIR}) in child CMakeLists.txt
without the need to do so manually.
Searched the documentation to no avail. Did I just imagine this option or is
it there somewhere?
Thanks!
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
___
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] autoheader
On Monday 30 March 2009 16:58:47 Bill Hoffman wrote: > I think you could do this pretty easily in a function, and a command > would not be needed. Anyway, does the API look good? Looks good to me! -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator Background Image/Custom .DS_Store support
On Thursday 05 February 2009 18:27:06 David Cole wrote: > I agree with Clint. This belongs in the new cmCPackDragNDropGenerator. Any updates on this getting merged? I'm happy to make changes and I'd really like to see this hit 0.6.4. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator DMG Volume Name/Compression Type variable support
On Wednesday 18 March 2009 17:51:47 Clinton Stimpson wrote: > I like that better. With the CPACK_DMG_* variables, one can even have > the PackageMaker generator use those variables. Any updates on this getting merged? I'm happy to make changes and I'd really like to see this hit 0.6.4. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] How best to capture the current Date/Time
On Friday 20 March 2009 13:26:36 Michael Jackson wrote: > After all of this I'll probably put in a feature request for this > functionality to be a part of CMake. Actually, if we could just get > the following variables set by CMake it would be great: > > CMAKE_CURRENT_YEAR > CMAKE_CURRENT_MONTH > CMAKE_CURRENT_DAY > CMAKE_CURRENT_HOUR > CMAKE_CURRENT_MINUTE > CMAKE_CURRENT_SECOND > > that would be _really_ helpful. I agree, this is something I've always been a bit surprised that it isn't in CMake. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator Background Image/Custom .DS_Store support
On Thursday 05 February 2009 18:27:06 David Cole wrote:
> I agree with Clint. This belongs in the new cmCPackDragNDropGenerator.
Please find attached a new patch for the DND generator. Sorry about the delay!
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
--- Source/CPack/cmCPackDragNDropGenerator.cxx 24 Feb 2009 14:34:03 - 1.5
+++ Source/CPack/cmCPackDragNDropGenerator.cxx 18 Mar 2009 18:33:24 -
@@ -177,6 +177,15 @@
std::string cpack_license_file =
this->GetOption("CPACK_RESOURCE_FILE_LICENSE") ?
this->GetOption("CPACK_RESOURCE_FILE_LICENSE") : "";
+
+ const std::string cpack_dmg_background_image =
+this->GetOption("CPACK_DMG_BACKGROUND_IMAGE")
+? this->GetOption("CPACK_DMG_BACKGROUND_IMAGE") : "";
+
+ const std::string cpack_dmg_ds_store =
+this->GetOption("CPACK_DMG_DS_STORE")
+? this->GetOption("CPACK_DMG_DS_STORE") : "";
+
// only put license on dmg if is user provided
if(!cpack_license_file.empty() &&
cpack_license_file.find("CPack.GenericLicense.txt") != std::string::npos)
@@ -216,6 +225,63 @@
}
}
+ // Optionally add a custom .DS_Store file
+ // (e.g. for setting background/layout) ...
+ if(!cpack_dmg_ds_store.empty())
+{
+cmOStringStream package_settings_source;
+package_settings_source << cpack_dmg_ds_store;
+
+cmOStringStream package_settings_destination;
+package_settings_destination << staging.str() << "/.DS_Store";
+
+if(!this->CopyFile(package_settings_source, package_settings_destination))
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Error copying disk volume settings file. "
+"Check the value of CPACK_DMG_DS_STORE."
+<< std::endl);
+
+ return 0;
+ }
+}
+
+ // Optionally add a custom background image ...
+ if(!cpack_dmg_background_image.empty())
+{
+cmOStringStream package_background_source;
+package_background_source << cpack_dmg_background_image;
+
+cmOStringStream package_background_destination;
+package_background_destination << staging.str() << "/background.png";
+
+if(!this->CopyFile(package_background_source,
+package_background_destination))
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Error copying disk volume background image. "
+"Check the value of CPACK_DMG_BACKGROUND_IMAGE."
+<< std::endl);
+
+ return 0;
+ }
+
+cmOStringStream temp_background_hiding_command;
+temp_background_hiding_command << this->GetOption("CPACK_COMMAND_SETFILE");
+temp_background_hiding_command << " -a V \"";
+temp_background_hiding_command << package_background_destination.str();
+temp_background_hiding_command << "\"";
+
+if(!this->RunCommand(temp_background_hiding_command))
+ {
+cmCPackLogger(cmCPackLog::LOG_ERROR,
+ "Error setting attributes on disk volume background image."
+ << std::endl);
+
+ return 0;
+ }
+}
+
// Create a temporary read-write disk image ...
std::string temp_image = this->GetOption("CPACK_TOPLEVEL_DIRECTORY");
temp_image += "/temp.dmg";
___
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] Bundle Generator DMG Volume Name/Compression Type variable support
On Wednesday 18 March 2009 17:51:47 Clinton Stimpson wrote: > I like that better. With the CPACK_DMG_* variables, one can even have > the PackageMaker generator use those variables. Have you had a chance to check it works correctly? I've not tested it extensively as it's basically identical to the old patch. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator DMG Volume Name/Compression Type variable support
On Wednesday 18 February 2009 12:31:25 Mike Arthur wrote:
> Please review the attached patch for inclusion.
>
> It adds support to the bundle generator to allow customisation of the
> volume name and hdiutil compression type used to create the DMG.
A new version of this patch against the DND generator (due to changes in CMake
CVS) is attached to this email and to the bug report at:
http://www.cmake.org/Bug/view.php?id=8759
I welcome any feedback!
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
--- Source/CPack/cmCPackDragNDropGenerator.cxx 24 Feb 2009 14:34:03 - 1.5
+++ Source/CPack/cmCPackDragNDropGenerator.cxx 18 Mar 2009 15:38:31 -
@@ -173,6 +173,15 @@
const std::string cpack_package_icon = this->GetOption("CPACK_PACKAGE_ICON")
? this->GetOption("CPACK_PACKAGE_ICON") : "";
+ const std::string cpack_dmg_volume_name =
+this->GetOption("CPACK_DMG_VOLUME_NAME")
+? this->GetOption("CPACK_DMG_VOLUME_NAME")
+: this->GetOption("CPACK_PACKAGE_FILE_NAME");
+
+ const std::string cpack_dmg_format =
+this->GetOption("CPACK_DMG_FORMAT")
+? this->GetOption("CPACK_DMG_FORMAT") : "UDZO";
+
// Get optional arguments ...
std::string cpack_license_file =
this->GetOption("CPACK_RESOURCE_FILE_LICENSE") ?
@@ -226,7 +235,7 @@
temp_image_command << " -ov";
temp_image_command << " -srcfolder \"" << staging.str() << "\"";
temp_image_command << " -volname \""
-<< this->GetOption("CPACK_PACKAGE_FILE_NAME") << "\"";
+<< cpack_dmg_volume_name << "\"";
temp_image_command << " -format UDRW";
temp_image_command << " \"" << temp_image << "\"";
@@ -394,7 +403,8 @@
cmOStringStream final_image_command;
final_image_command << this->GetOption("CPACK_COMMAND_HDIUTIL");
final_image_command << " convert \"" << temp_image << "\"";
- final_image_command << " -format UDZO";
+ final_image_command << " -format ";
+ final_image_command << cpack_dmg_format;
final_image_command << " -imagekey";
final_image_command << " zlib-level=9";
final_image_command << " -o \"" << outFileName << "\"";
___
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] MACOSX_BUNDLE_ICON_FILE bug
On Saturday 14 March 2009 14:23:51 Michael Jackson wrote: > Well I thought that was what I was supposed to do. If I give it the > path then it automatically gets installed into the bundle. Obviously > that will not work without some modifications/bug fix to CMake. > > What installation code are you using? I'm not any more, I'm now using the Bundle CPack generator. I believe I just installed it to "Resources" or to ".". -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] MACOSX_BUNDLE_ICON_FILE bug
On Saturday 14 March 2009 14:04:22 Michael Jackson wrote: > Is it a bug that CMake is putting in the absolute path to my icon file > instead of just the name? You gave it an absolute path though? I got it working fine when I just installed the icon into the bundle and then set the location afterwards. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] open source project for CMake ports?
On Saturday 07 March 2009 20:45:55 Philip Lowman wrote: > I have no plans to develop a package manager from the work done in > CMakePorts. As I've stated in other mailing lists like sldev, I think that > would be a waste of time. My apologies, rereading the messages that led me to draw that conclusion has led me to a new conclusion: don't read mailing lists when you are very tired! -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] open source project for CMake ports?
On Saturday 07 March 2009 11:08:43 Pau Garcia i Quiles wrote: > Whatever happened to this? It's here: http://code.google.com/p/cmakeports/ People are talking on the group list here and some stuff has been committed. Unfortunately I personally have the feeling that it's starting as a bit overengineering from day one and is turning into (yet another) package manager rather than just a collection of CMake'd buildsystems as described earlier. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] functions & custom commands- what's the trick?
On Friday 20 February 2009 08:22:59 Aaron Turner wrote: > I seem to be missing something painfully obvious, but I'm not sure what. You don't enter it into add_custom_command, that's for shell commands., just enter "clean_standard_files()" into your CMakeLists. You can't run CMake functions at "Make" time though, only "CMake" time (which will only be called to first generate or if the CMake files have changed). -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator DMG Volume Name/Compression Type variable support
Please review the attached patch for inclusion.
It adds support to the bundle generator to allow customisation of the volume
name and hdiutil compression type used to create the DMG.
--
Mike Arthur
Software Engineer
Mendeley Ltd.
--- Source/CPack/cmCPackBundleGenerator.cxx 22 Jan 2009 18:56:13 - 1.9
+++ Source/CPack/cmCPackBundleGenerator.cxx 18 Feb 2009 11:43:15 -
@@ -105,6 +105,16 @@
this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND")
? this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND") : "";
+ const std::string cpack_bundle_dmg_volume_name =
+ this->GetOption("CPACK_BUNDLE_DMG_VOLUME_NAME")
+ ? this->GetOption("CPACK_BUNDLE_DMG_VOLUME_NAME")
+ : this->GetOption("CPACK_PACKAGE_FILE_NAME");
+
+ const std::string cpack_bundle_dmg_format =
+ this->GetOption("CPACK_BUNDLE_DMG_FORMAT")
+ ? this->GetOption("CPACK_BUNDLE_DMG_FORMAT")
+ : "UDZO";
+
// The staging directory contains everything that will end-up inside the
// final disk image ...
cmOStringStream staging;
@@ -212,7 +222,7 @@
temp_image_command << " -ov";
temp_image_command << " -srcfolder \"" << staging.str() << "\"";
temp_image_command << " -volname \""
-<< this->GetOption("CPACK_PACKAGE_FILE_NAME") << "\"";
+<< cpack_bundle_dmg_volume_name << "\"";
temp_image_command << " -format UDRW";
temp_image_command << " \"" << temp_image.str() << "\"";
@@ -282,7 +292,8 @@
cmOStringStream final_image_command;
final_image_command << this->GetOption("CPACK_COMMAND_HDIUTIL");
final_image_command << " convert \"" << temp_image.str() << "\"";
- final_image_command << " -format UDZO";
+ final_image_command << " -format ";
+ final_image_command << cpack_bundle_dmg_format;
final_image_command << " -imagekey";
final_image_command << " zlib-level=9";
final_image_command << " -o \"" << outFileName << "\"";
___
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] ccmake not built on Linux 64
On Tuesday 17 February 2009 20:30:07 Michael Jackson wrote: > Yep. Silly me, expecting ncurses to be installed by default.. It is, just not the development headers. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] CMAKE_INTDIR / CMAKE_CFG_INTDIR
On Tuesday 17 February 2009 17:34:20 Pau Garcia i Quiles wrote: > I want Visual C++ to output executables, DLLs, etc to the builddir > without creating "Release", "Debug", "RelWithDebInfo", etc > directories. In our case, this would be very convenient for debugging. > > I have found the CMAKE_INTDIR and CMAKE_CFG_INTDIR variables but > neither SET( CMAKE_INTDIR "." ) nor SET( CMAKE_CFG_INTDIR "." ) > achieve what I want (in the VC++ project, CMAKE_INTDIR still has the > release type value). Is it possible to change this value at all? How? > (SET_TARGET_PROPERTIES?) This can't be done (as far as I can tell). The only way of achieving something similar is to use NMake makefiles instead of using a MSVC project, which doesn't set CMAKE_INTDIR. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] open source project for CMake ports?
On Tuesday 17 February 2009 02:24:17 Alan W. Irwin wrote: > Of course, you can debate forever whether such a SF project would be > successful or not, but the only way to really know is to try it and see. > That is, start with something small and expand from there. I don't have > time to help with such a SF project myself at this time, but I think it is > a good idea that has a reasonable chance of success, and I would certainly > be cheering from the sidelines. I would suggest that we definitely give it a try but perhaps not on SourceForge, Google Code is far easier to use (in my opinion). -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] CMake Facebook group
On Monday 16 February 2009 16:09:19 Bill Hoffman wrote: > I have created a CMake Facebook group that is open to the public. If > you are on Facebook, please feel free to join. Link: http://www.facebook.com/group.php?gid=54596142422 -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] "unit" testing your CMakeLists.txt
On Monday 09 February 2009 20:15:33 Tyler Roscoe wrote: > Does anyone do anything like this? Are there tools around to help? Is > this a worthwhile thing to think about? I think this shouldn't be separate from the rest of your other TDD stuff that the non-buildsystem developers are doing. In my mind TDD makes no sense without a continuous integration system and this means your packaging should be integrated into the buildsystem so that every revision that is committed is built, tested and packaged and any other tasks are run (e.g. documentation generation). You can and should just set up the continuous integration system to ensure these stages are completed successfully (such as get it actually running the packaged installer and the like). Really I think going much beyond this is a bit overkill. We're dealing with a pretty complex project with external dependencies, multiple platforms/architectures and automatic packaging and subtle bugs just don't tend to creep into the buildsystem in the same way that they do with our C++ code. I think the only real important thing from the buildsystem is the result and therefore just making sure the application can be run correctly should be enough. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ 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] Bundle Generator Background Image/Custom .DS_Store support
Please review the attached patch for inclusion.
It adds support to the bundle generator to add a background image and
.DS_Store for people (like myself/Mozilla/Last.fm) who want CPack to be able
to set a nice background to the Bundle without having to manually convert it.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
--- source/Source/CPack/cmCPackBundleGenerator.cxx 2009-02-04 15:00:24.727403954 +
+++ cmake-patch/Source/CPack/cmCPackBundleGenerator.cxx 2009-02-05 14:12:28.439443802 +
@@ -105,6 +105,14 @@
this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND")
? this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND") : "";
+ const std::string cpack_bundle_dmg_background_image =
+this->GetOption("CPACK_BUNDLE_DMG_BACKGROUND_IMAGE")
+? this->GetOption("CPACK_BUNDLE_DMG_BACKGROUND_IMAGE") : "";
+
+ const std::string cpack_bundle_dmg_ds_store =
+this->GetOption("CPACK_BUNDLE_DMG_DS_STORE")
+? this->GetOption("CPACK_BUNDLE_DMG_DS_STORE") : "";
+
// The staging directory contains everything that will end-up inside the
// final disk image ...
cmOStringStream staging;
@@ -202,6 +210,63 @@
}
}
+ // Optionally add a custom .DS_Store file
+ // (e.g. for setting background/layout) ...
+ if(!cpack_bundle_dmg_ds_store.empty())
+{
+cmOStringStream package_settings_source;
+package_settings_source << cpack_bundle_dmg_ds_store;
+
+cmOStringStream package_settings_destination;
+package_settings_destination << staging.str() << "/.DS_Store";
+
+if(!this->CopyFile(package_settings_source, package_settings_destination))
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Error copying disk volume settings file. "
+"Check the value of CPACK_BUNDLE_DMG_DS_STORE."
+<< std::endl);
+
+ return 0;
+ }
+}
+
+ // Optionally add a custom background image ...
+ if(!cpack_bundle_dmg_background_image.empty())
+{
+cmOStringStream package_background_source;
+package_background_source << cpack_bundle_dmg_background_image;
+
+cmOStringStream package_background_destination;
+package_background_destination << staging.str() << "/background.png";
+
+if(!this->CopyFile(package_background_source,
+package_background_destination))
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Error copying disk volume background image. "
+"Check the value of CPACK_BUNDLE_DMG_BACKGROUND_IMAGE."
+<< std::endl);
+
+ return 0;
+ }
+
+cmOStringStream temp_background_hiding_command;
+temp_background_hiding_command << this->GetOption("CPACK_COMMAND_SETFILE");
+temp_background_hiding_command << " -a V \"";
+temp_background_hiding_command << package_background_destination.str();
+temp_background_hiding_command << "\"";
+
+if(!this->RunCommand(temp_background_hiding_command))
+ {
+cmCPackLogger(cmCPackLog::LOG_ERROR,
+ "Error setting attributes on disk volume background image."
+ << std::endl);
+
+ return 0;
+ }
+}
+
// Create a temporary read-write disk image ...
cmOStringStream temp_image;
temp_image << this->GetOption("CPACK_TOPLEVEL_DIRECTORY") << "/temp.dmg";
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL dependencies
On Wednesday 28 January 2009 20:41:38 Pau Garcia i Quiles wrote: > Is it possible to install a target's dependencies using the INSTALL( > TARGET ... ) signature? I. e. something like INSTALL ( TARGET mytarget > INSTALL_DEPENDENCIES ) which goes through the parameters of > TARGET_LINK_LIBRARIES and installs them too. The GetPrerequisites is designed exactly for this. It's a bit tricky to use but I use it to install dependencies for my executables. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Monday 26 January 2009 21:53:18 Timothy M. Shead wrote: > I'm looking at an up-to-date CMake source tree, and I don't see this > generator ... can you explain what it is? Apologies, PackageMaker generator is what I meant. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Saturday 17 January 2009 01:40:27 Timothy M. Shead wrote: > Agreed - as I mentioned before, I understand that if you don't have a > bundle, running a GUI application out of the build directory is > problematic (for those unfamiliar: your program runs, but the window > manager doesn't provide any decorations for your windows, so everything > gets stuck in the top-left-corner of the screen and you can't move / > resize / close them). > > What I was leading-up-to was that we need to make a distinction between > "build bundles" that are created as a convenience for running > applications out of the build directory, and "package bundles" that are > created as part of the packaging process. For example, if you have > > ADD_EXECUTABLE(foo ... MACOSX_BUNDLE) > INSTALL(TARGETS foo DESTINATION bin) > > I gather that there is some special-case logic in the install-generation > code that handles installing the bundled binary, the auto-generated > plist, etc. Now suppose that the special-case code were removed, so > that just the binary - even though it's bundled in the build directory - > goes to the bin directory at install-time just as it would on any other > platform. With this behavior in place, you would avoid the > "bundle-within-a-bundle" problem, and you would write package generators > that would be smarter - i.e. duplicate much of the functionality of > build-bundling by default, but allow sufficient configuration to handle > more complex packaging scenarios. I think it's worth look at the PackageKit generator which does this properly. I guess I just want to make sure that whatever is decided, moving on, there are clear and consistent ways to make bundles and you avoid the bundle within a bundle problem. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Obtaining dependencies of static libraries
On Thursday 22 January 2009 23:26:47 Robert Dailey wrote: > With all do respect, why does it matter? Yes, in the generated target > dependencies are handled for me but when I call get_target_property() with > LINK_INTERFACE_LIBRARIES it only includes the dependencies I specific for > only that executable target, it does not provide me the transitive > dependencies. This is a problem for me. It matters because: a) You're asking for help on a list of mostly volunteers so sometimes we ask why you're doing something so we can direct you if you've just missed something in CMake. b) You may have uncovered a bug in CMake and we'd like to help make CMake better than it is. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Recompile with different flags
On Monday 19 January 2009 20:02:34 Adam Weiss wrote: > I have a set of source files that are compiled and built into a library. > Works great. > Now I want to recompile those same files with a compiler flag added into > another library. Don't ask, this is how it has to be. Purely for intellectual curiosity, why does this have to be? No worries if you don't have time to reply to this, I'm just interested by other peoples configurations :) -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 19:12:55 Clinton Stimpson wrote: > To add this capability to the Bundle generator, how about just checking > if CPACK_BUNDLE_NAME is not set? If its not set, then simply take the > install tree, and add a /Applications link, maybe a few other options to > make it fancy, and dmg-ify it. Seems in that case it would be a very > simple generator, as I really want my "make install" tree to work. And > in my case where I want a top level directory containing multiple > bundles and files, I could just set the CPACK_PACKAGING_INSTALL_PREFIX > to get the same behavior as the PackageMaker generator. Personally I think that behaviour would be pretty confusing as I'd argue the CPACK_BUNDLE_NAME should be set by default to the project name, for instance. I think the Bundle generator should (continue to) create the bundle, not rely on one from MACOSX_LOCATION and that you should probably just change your buildsystem rather than trying to change the generator to meet a scenario that only you seem to want. Sorry to be blunt, apologies for my rudeness, I just want to make sure that the Bundle generator improves its consistency in CPack rather than getting worse. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 16:54:22 David Cole wrote: > What Clinton wants, though, is the ability to just put his make install > tree into the .dmg, not put it inside another bundle. His make install tree > contains a bundle already. I'd strongly argue that CMake already has too much duplication on this front. Either the MACOSX_BUNDLE property should be used for all CPack generators, none or removed completely and CPack used for generating bundles instead. It's exceptionally confusing for someone who comes to CMake having not used it for Mac packaging before to find three ways of doing it, all having slightly different features... -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 16:10:18 David Cole wrote: > I would recommend modifying the existing bundle generator to keep its > current behavior for backwards compatibility *and* add to its behavior such > that it can produce a drag-n-drop installer for your "make install" tree. > > If that proves too difficult in terms of coding or seems otherwise > unadvisable then I would say we should add a new "drag-n-drop bundle > generator" to CPack that does the "/Applications" shortcut thing and places > either a single folder of your make install tree or the contents of your > make install tree next to the /Applications shortcut. It basically should do that already, it's just a question of sensible defaults which are somewhat lacking currently. Basically, pretty much all the variables should probably keep the ability to be manually set but should really get their defaults from elsewhere in CMake. I've got some local work on this but haven't turned it into a fully-fledged patch yet. > Seems like that might be a good solution. > > Anybody have time to work on such modifications / new class? I'm vaguely hacking on the Bundle generator when I get the chance but it takes a while to get stuff committed so I'll keep just posting on the mailing list any patches I do and keep them local. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 16:12:54 Michael Jackson wrote: > There was talk long ago (maybe on the ParaView list) about making a > DMG generator for CPack. My personal opinion is that developers that > are creating straight forward OS X applications that _only_ need to be > installed into /Applications or where ever the user wants should be > using a Drag and Drop DMG installer and NOT the actual OS X installer. > For more complex applications that require putting files in several > locations (like data base apps, server apps .. ) need the power of the > actual installer. Sorry, how is this _not_ the Bundle generator? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 16:01:55 Clinton Stimpson wrote: > I've already done this, so when I do a "make install," I get all my > bundles with install names fixed, with prerequisites, etc... It works > fine with CPack/PackageMaker generator which also makes the top level > folder to contain all the apps, so it installs nicely except for a root > ownership problem. But it doesn't work with the CPack/Bundle generator > since it tries to re-bundle the bundles that I've already got. I guess > I could take the last two easy steps, make the /Applications link and > the dmg myself. Seems to me those two steps is all the cpack bundle > generator needs to be doing, and the rest of the work of creating the > bundle be done by the "make install" step. No? Maybe a new cpack/dmg > generator that just takes what make install gives, optionally adds a > softlink such as /Applications, and makes a dmg? There are three methods of making Bundles in CMake, you need to make sure you are only using one at a time. I'm guess you've set the MACOSX_BUNDLE parameter on your executable to cause this behaviour. The Bundle generator was written from outside of CMake and I agree it could do with a bit of a consistency cleanup. You can, however, get it working fine with a bit of work, my employers OSX packages use the CMake Bundle generator (http://www.mendeley.com) > I was impressed that what I had done to make a nice NSIS installer also > worked just fine with PackageMaker. I like that consistency. I didn't > see that with the bundle generator. Yeh, as I say, it needs a bit of work and to do a few more checks to stop you shooting yourself in the foot. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Friday 16 January 2009 15:05:55 Clinton Stimpson wrote: > Another question, can I have the bundle generator make another sub > folder, then I put two .app bundles in there, then when the user opens > the dmg, they see one folder they can drag to their /Applications which > contains multiple .app's. But there's still the problem of specifying > different plist, icons, etc... from global variables instead of just > using the ones I already set on the executables. > > Or does it not make sense to create installers like this? I think it makes sense, personally, but the Bundle generator doesn't support it. If you wanted to do it that way I guess I'd add component support (like the PackageMaker/NSIS installers support) to the Bundle generator. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack bundle generator qq
On Thursday 15 January 2009 20:25:46 Clinton Stimpson wrote: > Or are these bundles only supposed to have one application? Correct, an .app bundle can have other executables inside but 99% of users will never find them because double-clicking on the .app bundle will just run the assigned startup command. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack PackageMaker bug?
On Thursday 15 January 2009 20:17:55 Clinton Stimpson wrote: > The problem with PackageMaker is that ALL the files need to be owned by > root at package time. Not install time. That can only be done if I > issue "make package" as root, as "chown root" doesn't work as a normal > user. When I do that, most of my problem is solved. Then I just add an > install(CODE "chmod ...") to make sure the permissions are correct as > well. I don't see how a patch to CMake can help this PackageMaker > problem much. What you need is something like fakeroot for Linux but I'm not sure if that runs on OS X... -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 8
On Tuesday 13 January 2009 22:15:09 Bill Hoffman wrote: > I have a release candidate (RC 8) for 2.6.3 ready for CMake. Great, thanks! Any chance you reckon my hdiutil cpack fix might make it into 2.6.3? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Bundle Generator easily hits hdiutil MNAMELEN limit
On Wednesday 07 January 2009 20:12:33 David Cole wrote:
> *Using this technique* would be an acceptable patch to fix the bug. CPack
> is not going to provide a tmp file name API and wanting to mount a *.dmg
> file is not a reasonable thing to do in an arbitrary CMake build tree
> (because of the stupid 90 character limit). Sorry I do not presently have
> time to work on such a patch in the near term but if one were to appear
> (that analyzes hdiutil output instead of forcing a -mountroot argument)
> then it would have a higher likelihood of being applied.
Done, find attached to this email and on the bug:
http://public.kitware.com/Bug/view.php?id=7523
Let me know your thoughts.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
diff -dur source/Source/CPack/cmCPackBundleGenerator.cxx cmake-patch/Source/CPack/cmCPackBundleGenerator.cxx
--- source/Source/CPack/cmCPackBundleGenerator.cxx 2009-01-08 13:00:31.322952596 +
+++ cmake-patch/Source/CPack/cmCPackBundleGenerator.cxx 2009-01-08 12:56:17.458952637 +
@@ -19,6 +19,8 @@
#include "cmCPackLog.h"
#include "cmSystemTools.h"
+#include
+
//--
cmCPackBundleGenerator::cmCPackBundleGenerator()
{
@@ -245,16 +247,14 @@
if(!cpack_package_icon.empty())
{
cmOStringStream temp_mount;
-temp_mount << this->GetOption("CPACK_TOPLEVEL_DIRECTORY") << "/mnt";
-cmSystemTools::MakeDirectory(temp_mount.str().c_str());
cmOStringStream attach_command;
attach_command << this->GetOption("CPACK_COMMAND_HDIUTIL");
attach_command << " attach";
-attach_command << " -mountpoint \"" << temp_mount.str() << "\"";
attach_command << " \"" << temp_image.str() << "\"";
-if(!this->RunCommand(attach_command))
+std::string attach_output;
+if(!this->RunCommand(attach_command, &attach_output))
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
"Error attaching temporary disk image."
@@ -263,6 +263,10 @@
return 0;
}
+cmsys::RegularExpression mountpoint_regex(".*(/Volumes/.*)\n");
+mountpoint_regex.find(attach_output.c_str());
+temp_mount << mountpoint_regex.match(1);
+
cmOStringStream setfile_command;
setfile_command << this->GetOption("CPACK_COMMAND_SETFILE");
setfile_command << " -a C";
@@ -335,14 +339,14 @@
}
//--
-bool cmCPackBundleGenerator::RunCommand(cmOStringStream& command)
+bool cmCPackBundleGenerator::RunCommand(cmOStringStream& command,
+ std::string* output)
{
- std::string output;
int exit_code = 1;
bool result = cmSystemTools::RunSingleCommand(
command.str().c_str(),
-&output,
+output,
&exit_code,
0,
this->GeneratorVerbose,
diff -dur source/Source/CPack/cmCPackBundleGenerator.h cmake-patch/Source/CPack/cmCPackBundleGenerator.h
--- source/Source/CPack/cmCPackBundleGenerator.h 2009-01-08 13:00:31.322952596 +
+++ cmake-patch/Source/CPack/cmCPackBundleGenerator.h 2009-01-08 12:56:17.458952637 +
@@ -41,7 +41,7 @@
const std::vector& files);
bool CopyFile(cmOStringStream& source, cmOStringStream& target);
- bool RunCommand(cmOStringStream& command);
+ bool RunCommand(cmOStringStream& command, std::string* output = 0);
std::string InstallPrefix;
};
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack Bundle Generator easily hits hdiutil MNAMELEN limit
>From the hdiutil manpage: -mountroot path mount volumes in path instead of in /Volumes. path must exist. Note that mountpoint paths must be less than MNAMELEN characters (90 as of this writing). This limit is easily hit by the mounting of the temporary dmg (tmp.dmg) in the Bundle Generator and causes it to fail. May I suggest that, instead of mounting into ./_CPack_Packages/OSX- Universal/Bundle/mnt/ instead /tmp/cpackmnt/ is used instead or the mountpoint parameter omitted and the Volumes mountpoint is used instead? I can write a patch if necessary but it should be a trivial fix (if agreed). -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeEd Eclipse Plugin version 1.1.0 Now Available
On Tuesday 30 December 2008 17:02:48 Michael Jackson wrote: > On behalf of C Thing Software and BlueQuartz Software I would like > to announce the final release of the CMakeEd Eclipse Plugin. Great, thanks for this Mike, great work! > The sourceforge website is <http://cmakeed.sourceforge.net> > Downloads are available at > <http://sourceforge.net/project/showfiles.php?group_id=193949&package_id=22 >8545 Any reason this isn't in the update site (yet) ? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tuesday 09 December 2008 22:33:22 Robert Dailey wrote: > I have a directory that contains DLL files that I need to copy to the > directory at which my executable is built. However, the DLL files that I > copy over are different depending on the configuration that was used to > build the executable. For example, if I've built my executable using the > DEBUG configuration, I need to copy over DLL files named foo_d.dll, > bar_d.dll. If RELEASE was used to build the executable, then I need to copy > over foo.dll and bar.dll. Since the debug/release executables are placed in > different directories by CMake when they are built, the destination > location for the DLLs also changes across configurations as well. Are you building these DLLs or are they binaries? If so, why does it need to be post-build and not pre-build? If the latter is acceptable then I've got a solution for you, we've used at my place of work. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
On Wednesday 03 December 2008 16:36:23 Bill Hoffman wrote: > I have a release candidate (RC 5) for 2.6.3 ready for CMake. Did my "PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND" ever get applied for 2.6.3? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking "make" with CMake scripts?
On Saturday 29 November 2008 03:36:20 Robert Dailey wrote: > The problem does indeed sound too complex for my needs, as you've > emphasized. I'm creating my own open source project which depends on the > Subversion library, and the subversion library has dependencies on APR, > Neon, and several other libraries. It's a big complex tree of dependencies > that I'm not sure how to handle. I'm new to open source projects so some > advice here might be helpful. At this point I'm getting a bit off topic so > I do apologize for that. My first thought on solving this problem, as > you've seen, is to try to use CMake to build everything. However now it > seems like a pretty bad idea. The typical way this is handled in both CMake and generally is that you rely on the builder of your sourcecode to have the dependencies already installed and then use Find* modules to determine if the libraries are installed and either block the build or adjust the options depending on what the user has installed. Having your build system build the other libraries or (even worse) having copies of them in your source tree is not a good idea as you need to keep up to date with their buildsystem and also apply any security fixes or whatever to your local version of the application. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode in Visual Studio projects
On Wednesday 26 November 2008 16:54:13 Robert Dailey wrote: > > I noticed when I run CMake for Visual Studio 9 2008 it sets my project to > > "Multibyte Character Set" instead of Unicode. Is there a way to force > > CMake to set the "Character Set" option to "Use Unicode Character Set"? In Visual Studio this just sets CFLAGS on the commandline. You can't actually change the option but you can set the CFLAGS to do the same thing. I can't remember what they are off the top of my head though and too busy to check. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Friday 07 November 2008 11:50:04 Jed Brown wrote: > It sounds like these all satisfy the predicate that you have shared libs > and you only have one version of each package installed (or you're > trying to find the version in the standard location). Sure and I'd argue most people are in that group. > I really don't intend to bash CMake. *I* like it much better than the > alternatives, but I'm trying to convince others and it's hard for me to > sell CMake while finding that many modules (most of which I don't > actually care about) are systematically broken in niche environments > which are disproportionately popular on clusters, an important > demographic for my projects. Cool, I just objected to your claims that it isn't "properly" cross-platform because that really hasn't met what I've encountered at all. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Friday 07 November 2008 11:02:37 Jed Brown wrote: > I had hoped that by raising the issue of widespread brokenness, there > would be some response from CMake developers about ways to fix it. It > seems like I'm still at the stage of convincing people that there is a > real problem. This is why I'm concerned that `cross-platform' may > actually mean `Ubuntu/Windows/Mac' in practice. I'm no Kitware employee but I do feel the need to defend CMake. I've used CMake on Debian, Red Hat, Fedora, Slackware, Gentoo, Windows XP, Windows Vista, OSX 10.4, OSX 10.5 and custom-rolled Linux distributions. I've used it across four architectures and four compilers. I've introduced it into two companies I've worked for and use it in my spare-time KDE development. I've never had any of the problems you described. That's not to say they don't exist but I think you're doing the classic software engineer thing (that I've been guilty of more than a few times) of assuming your specific circumstances are the norm and that if you have any problems then the application is broken for everyone else. This simply isn't the case. I haven't seen any of this "widespread brokenness" you claim. You seem to say that CMake doesn't work nicely for a specific use-case you have and it may not but there's no need to basically troll the whole project because of shortcomings in a niche environment. CMake may not be perfect but it's the best damned cross-platform build system I've seen for C/C++ by a _long_ way. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake generated build number?
On Wednesday 05 November 2008 14:00:18 Blezek, Daniel J. wrote: > I'd like to have a monotonically increasing "build number" auto > generated by CMake. This would be for official builds of the software, > so we could track algorithm changes / results. I'd also be happy if > CMake could pull the latest SVN revision number. This would go in a -D > during the build. See to the documentation for the "Subversion" module/package and the corresponding functions. I use them to do something very similar by getting the contents of the branch name and setting the application version depending on information extracted from that name. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND
Find the first patch attached, it makes the Bundle generator work without
CPACK_BUNDLE_STARTUP_COMMAND.
Patch is against latest CVS, please critique. I have commit access so can
commit if this meets approval.
Please see "[CMake] Bundle Generator conflicts with MACOSX_BUNDLE" for
discussion as to why this was necessary.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
--- source/Source/CPack/cmCPackBundleGenerator.cxx 2008-11-04 10:58:33.058664518 +
+++ cmake-patch/Source/CPack/cmCPackBundleGenerator.cxx 2008-11-04 11:03:42.162648246 +
@@ -113,22 +113,14 @@
return 0;
}
- const std::string cpack_bundle_startup_command =
-this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND") ?
-this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND") : "";
- if(cpack_bundle_startup_command.empty())
-{
-cmCPackLogger(cmCPackLog::LOG_ERROR,
- "CPACK_BUNDLE_STARTUP_COMMAND must be set."
- << std::endl);
-
-return 0;
-}
-
// Get optional arguments ...
const std::string cpack_package_icon = this->GetOption("CPACK_PACKAGE_ICON")
? this->GetOption("CPACK_PACKAGE_ICON") : "";
+ const std::string cpack_bundle_startup_command =
+this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND")
+? this->GetOption("CPACK_BUNDLE_STARTUP_COMMAND") : "";
+
// The staging directory contains everything that will end-up inside the
// final disk image ...
cmOStringStream staging;
@@ -176,26 +168,29 @@
return 0;
}
- // Install a user-provided startup command (could be an executable or a
- // script) ...
- cmOStringStream command_source;
- command_source << cpack_bundle_startup_command;
+ // Optionally a user-provided startup command (could be an
+ // executable or a script) ...
+ if(!cpack_bundle_startup_command.empty())
+{
+cmOStringStream command_source;
+command_source << cpack_bundle_startup_command;
+
+cmOStringStream command_target;
+command_target << application.str() << "/" << cpack_bundle_name;
- cmOStringStream command_target;
- command_target << application.str() << "/" << cpack_bundle_name;
+if(!this->CopyFile(command_source, command_target))
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Error copying startup command. "
+" Check the value of CPACK_BUNDLE_STARTUP_COMMAND."
+<< std::endl);
- if(!this->CopyFile(command_source, command_target))
-{
-cmCPackLogger(cmCPackLog::LOG_ERROR,
- "Error copying startup command. "
- " Check the value of CPACK_BUNDLE_STARTUP_COMMAND."
- << std::endl);
+ return 0;
+ }
-return 0;
+cmSystemTools::SetPermissions(command_target.str().c_str(), 0777);
}
- cmSystemTools::SetPermissions(command_target.str().c_str(), 0777);
-
// Add a symlink to /Applications so users can drag-and-drop the bundle
// into it
cmOStringStream application_link;
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB Packaging: Automate dependency resolution
On Tuesday 04 November 2008 11:36:12 David Graf wrote: > How exactly to you use dpkg-shlibdeps? Because I get the following bug: > dpkg-shlibdeps: failure: cannot read debian/control: No such file or > directory You really should be using Debian utilities. I talked to several Debian developers about CMake's DEB support and they said it was "worse than useless" because it doesn't follow the Debian packaging guide at all. I'd advise that you therefore use the Debian development tools when creating packages rather than writing scripts yourself. I hope to work on this at some stage but can't justify doing it at work yet. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Sunday 02 November 2008 03:29:36 Timothy M. Shead wrote: > That's the (untested) idea - although it occurs to me that the copy > command may try to copy the symlink target instead of the link itself. Right, changes I'd advocate or am currently working on: - Don't make CPACK_BUNDLE_STARTUP_COMMAND mandatory for people who want to manually install to the correct location (../MacOS) as you have to do the same for Frameworks and therefore its not actually needed. Alternatively, don't fail when you can't copy the target. - Again, don't make CPACK_BUNDLE_ICON mandatory as bundles work fine without a set icon. - Provide a default Info.plist (similar to Modules/CPack.Info.plist.in) and set sensible using the correct variables. - Use sensible defaults from CPack variables e.g. CPACK_BUNDLE_NAME should default to PROJECT_NAME - Allow specifying a custom .DS_Store and background.png file to be added into the DMG. Which of the above do you think you will implement and what is any sort of approximate timescale? I'm going to work on the first and possibly last as I need their functionality in the next week and I'll attach a patch against the current CVS when they are working for me. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Tuesday 04 November 2008 01:31:26 Michael Jackson wrote: > Take a look at the cmake wiki as there is a short write up on how to > use the BundleUtilities and you can also download my Qt base sample > project which also uses the BundleUtilities. > > http://www.bluequartz.net/software/files/QTTest.tar.gz > > http://www.cmake.org/Wiki/BundleUtilitiesExample > > I'm not sure where the functionality belongs. I believe if you do a > CPack with a destdir set or something like that then the App bundle > will be created and put into the installer. Thanks for that, but it doesn't generate the DMG for me as well and means I'll have a very different procedure for packaging on Mac from Windows and Linux. I'm working on some patches to fix the issues with the Bundle Generator, will attach some later today. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Sunday 02 November 2008 03:29:36 Timothy M. Shead wrote: > That's the (untested) idea - although it occurs to me that the copy > command may try to copy the symlink target instead of the link itself. It copies the target. Can you please try and fix this for the next CMake release? It's pretty irritating that the only way to use the Bundle generator with any non-system libraries is currently by using a script. I'd argue that you also probably don't want to mandate CPACK_BUNDLE_STARTUP_COMMAND unless you are creating the Info.plist for people, otherwise it's really unnecessarily limiting. It's a bit annoying that people who want to do things the proper way (e.g. using install_name_tool) have to jump through hoops whereas it's incredibly easy and even recommended by you to use DYLD_LIBRARY_PATH rather than the recommended and Apple-provided install_name_tool. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Friday 31 October 2008 16:18:51 Timothy M. Shead wrote: > Of course, you still have to provide a mechanism so the executable can > be located when your user double-clicks your bundle. That's where > CPACK_BUNDLE_STARTUP_COMMAND comes-in ... it copies a bundle-specific > file into the Contents/MacOS directory. That file could be a symlink to > the actual executable, or a startup script. Note that it is *never* > intended to be the executable itself. Ah, ok, this wasn't fully understood. Can you suggest how I might make this a symlink? Just manually create a relative one and pass it to CPACK_BUNDLE_STARTUP_COMMAND? > * Although a relative DESTINATION path seems to work OK today, I'm not > sure whether it will / should be allowed by CMake in the long-term. You > can imagine that end-users would be pretty upset if a poorly-written > build scattered files around outside their chosen CMAKE_INSTALL_PREFIX. Yeh, agreed. I don't necessarily think using relative paths is bad but moreso relative above the CMAKE_INSTALL_PREFIX. > This is why I think the ideal solution is to: > * Provide CPACK_BUNDLE_STARTUP_COMMAND for those people who need to use > startup scripts. > * Provide a mechanism to automatically generate a symlink for everyone Yeh, that seems like a good solution now I've seen through why you've done things the way you have. Sorry if I was rude before or ungrateful for your work, I was just getting very frustrated with not being able to get it working. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] view execute_process command
On Thursday 30 October 2008 20:41:36 James Bigler wrote: > Is it possible to view the actual command run by an execute_process > command? I'm trying to debug a command that isn't getting the right set of > quotes or something, and I want to see the command as cmake would execute > them. It would be good to know this but I tend to just copy the command itself into a MESSAGE(FATAL_ERROR) and read the output. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Thursday 30 October 2008 17:25:45 you wrote: > Yes, this is something I've been contemplating on a low-priority thread. > I've added this and your other suggestions to the wiki, no particular > guarantees on when I'll get to them. Obviously I realise this you aren't a Kitware employee so I'll excuse my apparent rudeness but I really question why this bundle generator is part of CMake at the moment, it is strangely incomplete. Something else I find strange which actually makes it unusable for me is way that CPACK_BUNDLE_STARTUP_COMMAND is manually copied into the MacOS/ directory. Combine this with this happening after "make install" is called and it makes it, as far as I can see, actually impossible to have "make package" generate a install_name_tool friendly app bundle, even with extensive work being done with INSTALL(SCRIPT) calls. Perhaps I'm just being stupid but if you can't help with the above can I perhaps submit a patch to do so? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Wednesday 29 October 2008 16:11:39 Timothy M. Shead wrote: > Let me know whether the new writeup would have helped. In the meantime > I'll have a look at how the generator can detect this situation at > package-time ... I've been successful in getting the Bundle Generator working (albeit with needing a few hacks that I'll document later and should probably be changed). Are you using it with BundleUtilities? If not you should think of how you could do, as manually having to run install_name_tool when BundleUtilities is available is a bit of a unpleasant proposition. Generally I'm pretty confused as to why most of the CPack logic seems to be in C++ and not in CMake itself, where it could be more easily modified and actually hook into the provided CMake modules functionality which, in cases like this, prove very useful. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bundle Generator conflicts with MACOSX_BUNDLE
On Wednesday 29 October 2008 16:11:39 Timothy M. Shead wrote: > Let me know whether the new writeup would have helped. In the meantime > I'll have a look at how the generator can detect this situation at > package-time ... Yeh, that would have helped, thanks. Other thoughts: - You should probably default to the CPack.Info.plist used for the MACOSX_BUNDLE property and populate it with sane values from CPack if a manual Info.plist wasn't specified (as some of us don't want to manually create it and find the MACOSX_BUNDLE ones fine) - Is there no current way of adding arbitrary files (e.g. a DS_Store/background.png) into the DMG? How hard would it be to implement this manually using CMake? Can you hook in at that level (I tried but failed). -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Bundle Generator conflicts with MACOSX_BUNDLE
The subject says it all, the CPACK Bundle Generator conflicts with MACOSX_BUNDLE and produces two nested Bundles. This should probably be checked for and/or documented because I assumed the two were related and wasted a fair bit of time working out that they weren't. Nice work though on both counts! -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How is GetPreRequisites used?
On Tuesday 28 October 2008 13:35:46 Michael Jackson wrote: > In what way are you trying to use GetPreRequisites? I have a Qt Based > app that uses GetPreRequisites indirectly through the OS X app bundle > building cmake module (BundleUtilities.cmake). > > I think on each system (Linux, OS X, Windows) there are different > solutions. Which system are you working on? All three systems. I've managed to get something working by making a CMake script file that uses it to get the resulting libraries and install them. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How is GetPreRequisites used?
Perhaps I'm just being stupid but I can't see how this can be used as it needs to be called at installation time and I'm not aware that modules can be? Does anyone have a working example of how to install its outputted libraries? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GetPrequisites ldd regex incorrect (with fix)
On Friday 24 October 2008 14:49:49 David Cole wrote: > Ah ha. Thanks for that. I will commit this today to CVS HEAD... I'm not sure if this works fully yet though. Should the regexp match just the library name or the full path? I'm not quite sure how I would be meant to use GetPrerequisites to install some libraries. Also, the "system" detection seems to not work on Linux either. Presumably you'd welcome a patch on this stuff. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] GetPrequisites ldd regex incorrect (with fix)
in get_prerequisites:
set(gp_regex "^\t([\t ]+)[\t ].*${eol_char}$")
which is missing a '^' before the second \t so should be:
set(gp_regex "^\t([^\t ]+)[\t ].*${eol_char}$")
Without this fix, the ldd output will never match filenames. Should I file a
bug
on the bugtracker for this too?
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] GetPrequisites working for anyone?
I'm really real problems with GetPrequisites, anyone got it working with ldd on Linux? I get correct ldd output but the regex doesn't seem to be correct in matching... -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CPACK][NSIS] vendor name used in the install directory
On Thursday 23 October 2008 08:41:10 Nicolas Desprès wrote: > I would like to have the default install path in my installer to be > something like: > > c:\Program Files\Vendor\ProgName x.y Random personal comment: As a user I, and I know a lot of others, find this very annoying as if you aren't 100% sure of the vendor it makes finding their files difficult. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] configure_file and Source Control
On Wednesday 08 October 2008 16:06:27 LaViolette, Alan wrote: > Hi, I am using configure_file to produce some build varient files. I > need to have these output files in source control so other developers > can access the results without needeing to build this library. To do > this I need to checkout the output file before it is writen. > > Does anyone have a recommendation on how to do this? Could CMake > support this? > > My current idea is to run a script that will check them out before I run > CMake. I would prefer if I only checked them out if they are modified. > > I was also thinking I could have configure_file generate a temp file and > create a custom build rule to checkout and copy the file to the real > name. This isn't really a CMake answer but I'd strongly advocate not having build- generated files in source control. They will only need to build the library once. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [New Module] Protocol buffers
On Thursday 25 September 2008 17:36:52 Bill Hoffman wrote: > Please see here: > New modules added to the bug tracker are generally ignored. Patches for > existing ones are assigned to the maintainer. It would be nice if you could send the above links and close the bug instead rather than ignoring them. I realise its more work (also feeling the pain of a customer bug tracker here) but its infinitely more helpful. http://www.cmake.org/Bug/view.php?id=7691 This has a very simple patch but no comments or assignments and, as far as I can tell from the above links, the module is maintained by Kitware. I did post all my modules that I posted to the bug tracker to this mailing list too. I didn't put "[New Module]" in the subject line or attach the files, instead linking to the attachment in the bugtracker. Should I redo this? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [New Module] Protocol buffers
On Wednesday 24 September 2008 09:59:11 Esben Mose Hansen wrote: > Is there something I can do to move this onwards? > > Personally, I think it would be beneficial to have a repository with > experimental CMake modules, from which the kitware people could move > modules into the "official" build when they have been sufficiently tested. > After all, not many of us have experience with building under all the > supported platforms, so most of us will need help testing. On the other > hand, having all these modules sort of floating around on mailing list > would be suboptimal for a number of obvious reasons. Agreed, I've submitted a bunch of modules to the bugtracker and received no feedback on them or news about inclusion in the tree. It might be an idea for someone to create a Google Code project or something with unofficial modules which perhaps Kitware would link to and we can plaster over the wiki. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Dependencies and ADDITIONAL_MAKE_CLEAN_FILES
On Tuesday 23 September 2008 22:29:38 Phil Smith wrote: > How does CMAKE decide on its own that A.c is dependent on B.c, and that > compiling A.c thus requires compiling B.c? I'm somewhat confused by what you mean. In basic terms CMake is about creating libraries or executables. A library/executable will depend on all their listed source files and any other targets specified by target_link_libraries() or add_dependencies() > I've read the doc and Googled and looked at all the build.make and > depend.make files, and there's clearly some figurin' out going on, but I > don't understand it. A pointer or two would help here! 0x783bd319 0xb358ea34 (I'm not funny, excuse me) > So I'd like to tell "make clean" to delete .ASM and .LST files when it > deletes .o files. And ADDITIONAL_MAKE_CLEAN_FILES sounds like it's designed > to do that. But again, I can't figure out how to get it to do so. An > example would get me going, I'm sure. In the relevant source directory: set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES FOO.ASM BAR.LST) Hope this was helpful, if not, let me know and I'll try and explain better. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] the switch to subversion?
On Tuesday 23 September 2008 16:19:05 Michael Wild wrote: > git rocks! ;-) I agree but not everyone is happy using the console for their VCS. You move to git and you alienate said people. Subversion, on the other hand, has a lots of GUI tools available for such folks. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to relocate an OSX library
I've written a macro to relocate an OSX library. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7695 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to "install" files to the MSVC build directories
Visual Studio users expect to be able to click "Run" and have the application run correctly from the build directory. I've written a module that provides this functionality. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7694 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to get UNIX symlinks from a library's name
I've written a module get the associated symlinks for a library when given the library name or another */lib/* symlink on UNIX systems. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7693 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to get Qt .dll library location on Windows
I've written a simple module that gets the .dll file of a Qt library on Windows given the .lib file. I've found this pretty useful when installing libraries to be bundled with a dynamic Qt executable If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7692 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to provide QT_LIBRARIES_RELEASE and QT_LIBRARIES_DEBUG
I've written a module (based on some work from the archives here) that provides QT_LIBRARIES_RELEASE and QT_LIBRARIES_DEBUG variables for easier installation of dynamic Qt applications. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7691 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
On Tuesday 16 September 2008 20:13:15 Mike Arthur wrote: > I've written a CMake Module to do this that I've been meaning to add to the > CMake bugtracker for ages. I showed it to Alex Neundorf at Akademy and he > seemed very interested. Anyone else? Mike Jackson, I feel there are too many people called "Mike" in this thread. Fancy changing your name? ;) Anyway, the OSX relocation module I posted is here: http://public.kitware.com/Bug/view.php?id=7695 I'm going to post a separate message about this in case anyone else is interested and ignoring this thread. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
On Tuesday 16 September 2008 16:42:44 Mike Jackson wrote: > Philosophically I don't like the idea of > setting the DYLD_LIBRARY_PATH as that has some unknown implications > and would rather see a solution that runs install_name_tool over the > needed libraries to fix them up. Again, due to the lack of anything > else, your solution does work. I've written a CMake Module to do this that I've been meaning to add to the CMake bugtracker for ages. I showed it to Alex Neundorf at Akademy and he seemed very interested. Anyone else? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTest/test target customisation
I'm having some frustrations with trying to customise CTest's support in CMake. Our testing system does not involve using CDash/Dart but our own continuous integration system so as a result I want "make test" to run our tests and generate coverage information. Maybe I'm just being stupid but it seems almost impossible to customise what "make test" does or override it with my own version, whilst still having it run all the tests I've added with "add_test". Any ideas? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Add dependency to add_test
I'm trying to make add_test depend on the source of the test executable so if it is changed then running "make test" will regenerate the executable first. Any ideas? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Merging third-party modules upstream?
I've accumulated a fair amount of custom CMake modules, some written myself and some from other open-source projects. Is it possible to get any of these merged with CMake? If so, how would I/we go about doing this? I'm prepared to document/rewrite to better meet your conventions if necessary. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Debug libraries
On Monday 28 July 2008 19:14:51 Leopold Palomo-Avellaneda wrote: > One thing that i have not be able to solve is that when I create the MS > Visual Studio Project, in the Debug option, the Qt libraries are the debug > ones (with d) and in the release are the "normal" (without d). However, I > couldn't do the same with the others and I don't know how I can tell > MSStudio that when compile in Debug chose the debug ones. http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindLibraryWithDebug.cmake?view=markup That's what you want. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing OSX Frameworks
On Wednesday 23 July 2008 21:45:34 Shead, Timothy wrote:
> On 7/23/08 1:45 PM, "Bill Hoffman" <[EMAIL PROTECTED]> wrote:
> While I'm at it, is there a good way to install an external shared library
> that handles its' symlinks? I've been doing the following, which is
> less-than-satisfying:
I've got a slightly more cross-platform module I wrote to do this, based off
yours:
# Takes a name of a variable containing a library location and returns the
# ${LIBRARY}_AND_SYMLINKS variable which contains a list of the library and
# all its symlinks.
macro(get_library_and_symlinks LIBRARY)
get_filename_component(_LIBRARY_DIR "${${LIBRARY}}" PATH)
get_filename_component(_LIBRARY_NAME "${${LIBRARY}}" NAME_WE)
file(GLOB ${LIBRARY}_AND_SYMLINKS
${_LIBRARY_DIR}/${_LIBRARY_NAME}*${CMAKE_SHARED_LIBRARY_SUFFIX}*
)
endmacro(get_library_and_symlinks LIBRARY)
So to use it you might do e.g.:
get_library_and_symlinks(CLUCENE_LIBRARY)
install(FILES ${CLUCENE_LIBRARY_AND_SYMLINKS}
DESTINATION "${LIBRARY_INSTALL_DIRECTORY}"
)
--
Cheers,
Mike Arthur
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] get_filename_component ABSOLUTE doesn't work?
Maybe I don't understand the documentation but it seems to suggest it resolves symlinks? However, if I use this on e.g. /usr/lib/libmodulename.so which is symlinked to /usr/lib/libmodulename.so.0.0 then it doesn't seem to resolve. Any ideas? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing OSX Frameworks
On Wednesday 23 July 2008 16:06:21 Mike Jackson wrote: > What would probably be nice at this point would be an example OS X > centric project that uses all these ideas with code explanations for > each step. I think what would be nice is if CMake did this for us! If this is fairly standard when packaging on OSX then it would be good if there were some integration for this, even if we had to specify the relocations manually. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Static build against system/third-party libraries?
How can I get target_link_libraries to chose a static library over a dynamic so I can do a static build with CMake? Bonus points for a cross-platform solution! Thanks! -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPACK_NSIS_CREATE_ICONS incorrect
On Tuesday 22 July 2008 19:05:21 you wrote: > For some reason for me CPACK_NSIS_CREATE_ICONS is set incorrectly when > using an NSIS installer. My application is in c:\Program > Files\Mendeley\Mendeley.exe but it tries to point the start menu shortcut > to c:\Program Files\Mendeley\bin\Mendeley.exe. If I manually specify my CPACK_NSIS_CREATE_ICONS then these are created correctly but I don't think this should be necessary. I think this is a bug in the NSIS generator. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPACK_NSIS_CREATE_ICONS incorrect
For some reason for me CPACK_NSIS_CREATE_ICONS is set incorrectly when using
an NSIS installer. My application is in c:\Program
Files\Mendeley\Mendeley.exe but it tries to point the start menu shortcut to
c:\Program Files\Mendeley\bin\Mendeley.exe.
What am I doing wrong?
Find my CPack configuration below.
--
Cheers,
Mike Arthur
set(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_SOURCE_DIR}/Description.txt")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Mendeley Description Summary")
set(CPACK_PACKAGE_VENDOR "Mendeley Ltd.")
set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "6")
set(CPACK_PACKAGE_VERSION_PATCH "6")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "Mendeley")
set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "Mendeley")
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/License.txt")
set(CPACK_RESOURCE_FILE_README "${CMAKE_SOURCE_DIR}/ReadMe.txt")
set(CPACK_RESOURCE_FILE_WELCOME "${CMAKE_SOURCE_DIR}/Welcome.txt")
set(CPACK_STRIP_FILES TRUE)
set(CPACK_SOURCE_IGNORE_FILES
moc_*.cxx;ui_*.cxx;cmake_install.cmake;CMakeCache.txt;*.s3db;CMakeFiles)
set(CPACK_PACKAGE_EXECUTABLES "Mendeley" "Mendeley" )
if (WIN32)
set(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY} Mendeley")
set(CPACK_NSIS_MUI_ICON
"${CMAKE_SOURCE_DIR}/src/UI/Resources/winMendeley.ico")
set(CPACK_NSIS_MUI_UNIICON
"${CMAKE_SOURCE_DIR}/src/UI/Resources/winMendeley.ico")
set(CPACK_NSIS_INSTALLED_ICON_NAME "Mendeley.exe")
set(CPACK_NSIS_DISPLAY_NAME "Mendeley Display Name")
set(CPACK_NSIS_HELP_LINK "http:www.mendeley.com")
set(CPACK_NSIS_URL_INFO_ABOUT "http:www.mendeley.com")
set(CPACK_NSIS_CONTACT "[EMAIL PROTECTED]")
set(CPACK_NSIS_MODIFY_PATH ON)
set(CPACK_PACKAGE_ICON
"${CMAKE_SOURCE_DIR}/src/UI/Resources/winNSISHeader.bmp")
set(CPACK_GENERATOR "NSIS;ZIP")
set(CPACK_SOURCE_GENERATOR "ZIP")
endif (WIN32)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Installing OSX Frameworks
Has anyone worked out a nice way of installing the needed OSX frameworks into my application bundle? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPACK_SET_DESTDIR
What does CPACK_SET_DESTDIR actually do? I can't find it documented anywhere but it seems needed for some CPack generators. CPack seems great but it's very poorly documented compared to CMake, even when using the wiki. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack: OS X PackageMaker installs into /Applications/$CMAKE_INSTALL_PREFIX
The PackageMaker created DMG installs my Program.app into /Applications/$CMAKE_INSTALL_PREFIX. Any idea why it is doing this, it seems pretty unlikely than anyone would ever want this behaviour? How can I stop this? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Staticly Link to VC++ Runtime
I'm trying to distribute my application to Windows users and am getting some fairly horrendous grief with manifests. Can anyone advise how I'd get CMake to statictly link against the msvc*.dll files that my application needs when compiled with MSVC++? Thanks! -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: Re: Survey: Are you using the Eclipse CDT Generator?
On Tuesday 15 July 2008 02:52:44 Miguel A. Figueroa-Villanueva wrote: > This is just a simple survey to get an idea if there are many people > successfully using the Eclipse CDT generator that has been out there > for a while. Not many bugs appear to be surfacing, so either it's in > pretty good shape or nobody is using it... ;) I was using it for a while but went back to creating my own projects using the Makefile generator. I thought you might like feedback as to why I did so. 1) I found it a bit annoying that the source tree was not the default location and instead was a linked directory. To me it makes more sense to have the build directory linked as you are more likely to be editing stuff in your source directory than your build directory. 2) It's good that all the rules are setup using Makefiles but I'm not quite sure why the "build" buttons seem to be disabled in favour of this. It would be good to have them re-enabled or at least an option so, if you'd like the default Eclipse behaviour (build button = make all) then you can have it easily. Otherwise it seemed to work fine for me, good work. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QTestlib CTest Integration
On Thursday 03 July 2008 16:40:31 you wrote: > So, QTestLib does a bunch of tests at one go, and produces its own > summery sort of like what ctest does? Yeh, I'll put the output at the bottom of this mail. I think this would not just help my current project but help KDE as well (which I hack on too). > No, I would still rather have that be clean output. However, I think > you can do this: Sorry, I'm still not being clear! I suck at communicating today! I don't mean make the default "ctest -V", obviously I don't expect you to change CMake just because I like it like that ;) What I meant is is there a variable I can set in my CMakeLists.txt to mean that "ctest -V" is called instead of "ctest". Anyway, the output with ctest -V: UpdateCTestConfiguration from :/home/mike/work/Mendeley/build/DartConfiguration.tcl Start processing tests UpdateCTestConfiguration from :/home/mike/work/Mendeley/build/DartConfiguration.tcl Test project /home/mike/work/Mendeley/build Constructing a list of tests Done constructing a list of tests Changing directory into /home/mike/work/Mendeley/build/src/Tests/Recognition_Tests 1/ 1 Testing Recognition_Tests Test command: /home/mike/work/Mendeley/build/bin/Recognition_Tests Test timeout computed to be: 9.99988e+06 * Start testing of RecognitionUtil_Test * Config: Using QTest library 4.4.0, Qt 4.4.0 PASS : RecognitionUtil_Test::initTestCase() PASS : RecognitionUtil_Test::GetPartsByMask_SepBySize_1() PASS : RecognitionUtil_Test::GetPartsByMask_SepBySize_2() PASS : RecognitionUtil_Test::RemoveLineWithOneWord_4() PASS : RecognitionUtil_Test::cleanupTestCase() Totals: 47 passed, 0 failed, 0 skipped * Finished testing of RecognitionUtil_Test * -- Process completed Passed 100% tests passed, 0 tests failed out of 1 -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QTestlib CTest Integration
On Thursday 03 July 2008 15:45:18 Bill Hoffman wrote: > Sorry to hear that... Can you be more specific about what is annoying > you? Just integrating the functionality of ctest and QTestLib in a way which doesn't hide all the QTestLib subtests. > Perhaps, what would it do? I don't know exactly yet. Probably something similar to "create_test_sourcelist" but instead of using a file for each test then using a QtTestlib test for each test. I think I'm correct in saying there is no support for test hierarchies, right? Like grouping tests? > No, the default is to produce nice clean pass/fail output for each test. > If your developers want to see the output, they can add -V. Sorry, should have been more clear. What I mean is it possible to make "ctest -V" the default when running "make test" from CMake. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QTestlib CTest Integration
I'm still battling with this, it's annoying me quite a lot. Would you guys accept a patch if I add this as a feature to CMake? In the meantime, is it possible somehow to force ctest to run as "ctest -V" so my developers can at least see the QTestLib output? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding C(XX)FLAGS by using an environment variable?
On Wednesday 02 July 2008 15:51:03 you wrote: > export CC='gcc -g' Is it just 'export CXX' for C++ compiler? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding C(XX)FLAGS by using an environment variable?
On Wednesday 02 July 2008 16:43:18 you wrote: > Huh.. I thought it actually made it look better. Beauty is in the > eyes of the beholder. :-) I guess my eyes are just better looking then ;) > You might just want to put and OPTION(..) in your cmake file to > toggle it on and off. Although each time you toggle the value > everything is going to get rebuilt because the flags get changed. I'm a fussy sod. Basically I want to be able to run make in Eclipse and have it build fine but when I go to the directory in a console be able to build it and get the same nice output as I currently do without that flag. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding C(XX)FLAGS by using an environment variable?
On Wednesday 02 July 2008 16:24:25 you wrote: > What problems does having the -fmessage-length=0 flag in a > makefile cause? It makes the output ugly if you are building from the console. Sounds like a lame reason I know! Really this is working around a limitation in Eclipse's CDT. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding C(XX)FLAGS by using an environment variable?
I'm wanting to try and add C(XX)FLAGS by using an environment variable so I can pass "-fmessage-length=0" only when compiling inside Eclipse. Is there any way to do this? CMake doesn't seem to respect C(XX)FLAGS as environment variables at "make" time. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating source code packages with Windo ws line endings
On Monday 23 June 2008 19:26:36 Mike Jackson wrote: > Could you list off the top of your head some of the tools that have > given you trouble? I have never run into the line ending issues yet > but I may in the future. I would be good to have an idea what tools > will NOT handle unix line endings. Notepad. You may think I'm joking but it becomes surprisingly annoying to open an e.g. CMakeLists file in Notepad and have it be unreadable so you have to open it up in another tool. Can't think of anything else I actually use that has that problem but the "default Windows editor" doesn't like them. -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding non-compiled files to project?
On Monday 23 June 2008 17:30:21 Timenkov Yuri wrote:
> Hmm, I don't think this should be a big deal:
>
> qt4_wrap_cpp(MyApp_MOC_SRCS ${MyApp_HDRS})
> source_group("Autogenerated MOC files" FILES ${MyApp_MOC_SRCS})
>
> I didn't try it, but this should work :)
> My be it worth filing feature request to bug tracker: automatically add Moc
> and UI files to such group in FindQt4.cmake like qmake does.
set(Common_MOC_HDRS ../../include/Common/AbstractMetadata.h)
qt4_wrap_cpp(Common_MOC_SRCS ${Common_MOC_HDRS})
add_library(Common ${Common_SRCS} ${Common_MOC_SRCS})
source_group("MOC Files\\Generated Files" FILES ${Common_MOC_SRCS})
No luck doing that in CMake 2.6.
--
Cheers,
Mike Arthur
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding non-compiled files to project?
On Monday 23 June 2008 16:36:53 Timenkov Yuri wrote: > Just add them to corresponding target. CMake won't try to compile them if > they don't have source file extension. If file has a source file extension, > you should set source files property HEADER_FILE_ONLY to true: ex: That seems to work great. The only problem I'm having now is how I apply source_group to files that are generated by other commands e.g. moc_* files from qt4_wrap_cpp Thanks! -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding non-compiled files to project?
It seems that the CMake Visual Studio 2008 project generator won't add any source files that it doesn't use in a add_executable or add_library call. I've tried manually adding others using source_group but this doesn't seem to make any difference. How do I add e.g. headers to my projects? -- Cheers, Mike Arthur ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
