Re: [CMake] CPack 101
On Thursday 23 December 2010, Mike McQuaid wrote: ... Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. We (I hope I speak for all CMake devs, here) take no offense. We welcome discussion, always. The mailing list is OK but most people don't want to sign up to a mailing list and receive lots of emails that have nothing to do with them. I'm only signed up because I want to try and get some patches merged and was told that I should discuss things here rather than the bugtracker. I hope I don't cause any offense here either. I'm passionate about CMake because I like the tool and want to make it better. The cmake wiki is a wiki, you are very welcome to get a login and start contributing to the cpack etc. pages :-) Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 22.12.10 23:24:35, Andreas Mohr wrote: - there's no cmake -E rename available (perhaps for reasons of build rule atomicity) Hmm my cmake -E help tells me different: ... rename oldname newname- rename a file or directory (on one volume) ... This is cmake version 2.8.2.20100804-ga42a4 Andreas -- You will be singled out for promotion in your work. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
To start with, Charm might be a good example of how to use CPack, it's an internal tool we've written in Qt and use CPack to do all the packaging: https://github.com/KDAB/Charm Check particularly the CMakeLists.txt and Charm/CMakeLists.txt for all the CPack-relevant logic. On 22 December 2010 17:57, KC Jones kc.jo...@skype.net wrote: I just don't think that CPack documentation and examples as they currently are published are sufficient or effective. I completely agree. More CPack example and tutorials would be very helpful. I see from archive searches that I'm not the first to suggest this. The Qt example is great, but the plugin support is overkill for most, and obfuscates much of the rest of the example. A step-wise tutorial format that starts with a working build, adds install target support, then adds CPack code would help my addled brain. Presenting newbies like me with a fully baked end result is helpful, but somewhat hard to digest. Agreed. A glossary, please. For instance bundle comes out of OS X, but now has some CMake-specific meaning for Linux and Win that I know is very important to me, but fully incomprehensible in my reading so far. Oh, and what are bundle keys? BundleUtilities is a really bad name. As I've said before, the naming stops Windows and Linux people from finding this functionality until they post on the mailing list or bugtracker. It's worth remembering that 90% (if not more) people won't even get here and will just use another tool. BundleUtilities/GetPrerequisites should really be rolled into CPack, I'd be pretty amazed if many people were using it outside of CPack. More meta docs please. Somewhere in my stumbling I found a decent diagram about how the ExternalProject module works. I think it was on the wiki, but I can't find it now. I would die for something similar that shows what install does and how it integrates with CPack. Same goes for BudleUtilities and other modules I've yet to discover. Really what's needed is less API documentation and more workflow documentation, perhaps based around user stories. If I just want to set up a CMake project and build a package there should be a step-by-step walk through the documentation. One final comment, cmake is elegant in the extreme. I can see from some of the wiki pages about how install is a merge that canonically folds multiple precursors into one uber-powerful, uber-flexible silver bullet. Impressive I'm sure. But harder to grok. I'm not suggesting that this is a wrong choice. But it is a barrier to learning. Where there is this kind of folding of advanced features into basic operations, some care is needed to ensure the docs convey the basics clearly. Agreed. WRT Cpack, what I find is that by merging it into CMake, the CPack code is declared one step away from where it is applied. The need for careful quoting in install(CODE ) blocks is a case in point. I'm sure this folding into a canonical, unified single CMakeLists.txt source is a good thing. But right now I feel like I'm learning Lisp again. Kind of mind blowing. Wishing I had some better training wheels to break this down for me... Thanks for your indulgence. I hope this does not offend those who've put so much into this great tool. I think integrating CPack into CMake is good but it hasn't been done very well. INSTALL(CODE) is just a mess and it would be good to be able to interact with CPack for typical usecases (e.g. use BundleUtilities to install all dependencies of an executable only at package time) and roll this into normal CPack syntax. I think the biggest problem is that people complain about CPack not being easy to use and are simply told how to do the task they've had the problem with and the bug/mail is ignored. The problem isn't the CPack functionality, it's accessing it and the lack of discoverability of it's features. I want to try and help and write patches for this stuff but I create bugs and they are ignored and then post on the mailing list and no-one from Kitware comments. I really appreciate that everyone is very busy but it feels like the CPack developers think it's good enough as-is and aren't particularly interested in attracted new contributions and improving the project. -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 22 December 2010 22:24, Andreas Mohr a...@lisas.de wrote: To put it simply, I was just not happy the entire time while trying to implement this and not finding any satisfying (well-crafted) solution, only ugly, very bad or semi-failing workarounds. That kind of work should be _fun_, especially when it then results in a nicely working and fully automated result. It plain wasn't. It's hard to understand exactly what your problems are other than just learning CMake. I suggest you make a new thread and try and explain these clearly, it's pretty hard to try and help from your previous descriptions. I have to say that so far I'm quite happy with the sufficiently large infrastructure that I was able to create, it's just that many areas feel wanting (the entire BundleUtilities / install-time stuff is an example of that, too). I agree. I think the install-time/CPack/dependency stuff needs some work. -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/22/2010 11:24 PM, Andreas Mohr wrote:
On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-requ...@cmake.org wrote:
Date: Wed, 22 Dec 2010 09:57:11 -0800
From: KC Jones kc.jo...@skype.net
Subject: [CMake] CPack 101
And I just don't seem to get it. I know this is very possible. I know this
is my own problem, first and foremost. So I'm exposing myself to potential
criticism here since RTFM and get a clue are probably the biggest part of
fixing my problem. Im not really asking for specific help on my code - I
might ask for that later. For now I just want to vent, hopefully in a
constructive way.
I have nothing to add about your particular description, but let me just
say that I can fully relate to how you feel, given that I hit a truly-WTF
situation just yesterday, too:
convert (imagemagick) appears to have incompatible versions which write
to either file.xpm.0 or file-0.xpm (and there's no option to specify
a specific file name prefix/format for icon series).
That is a bug in imagemagick then. Of course, you could do a
configure-check at CMake-time and figure out what naming scheme it uses
and then create your rules accordingly.
So, to convert an icon file, add an add_custom_command().
The problem then becomes how to know which file to choose
for subsequent COMMAND lines,
given that EITHER the one OR the other output file naming
is available after conversion.
[SNIP long list of failures]
That's 13 items of descriptions of failure (and I'm sure I forgot to
list some other failed avenues which I had been thinking about).
YUCK.
I don't know what the perfect answer here is (or possibly I'm just blind
for it?), but I know for certain that a simple Makefile rule
would have a lot more flexibility / simplicity,
and this simplicity is what CMake should strive to match
while keeping its current very nice full generator/platform abstraction.
Yes, of course that's hard, but IMHO the above story clearly shows that
_something_ appears to be much too involved about it, since there was
exactly no help at all anywhere, to defuse the situation to enable me
to reach a satisfying result. IOW implementation pressure due to
multiple CMake constraints is __MUCH__ too high, e.g. in the realms of line
feeds / permissions / symlinks especially (multiple discussion threads on the
internet about this).
You missed the obvious solution, as described above. Another solution is
that CMake is also a script-interpreter, and you can write arbitrary
scripts in the CMake language and then invoke them with ${CMAKE_COMMAND}
-P some_script.cmake in a custom command. In there you can do the full
thing: if(EXISTS ...), file(RENAME ...) etc.
Besides, simple Makefile rules won't help you on platforms without a
POSIX shell (e.g. Windows), so that would be even worse.
To put it simply, I was just not happy the entire time while
trying to implement this and not finding any satisfying (well-crafted)
solution,
only ugly, very bad or semi-failing workarounds.
That kind of work should be _fun_, especially when it then results in a
nicely working and fully automated result. It plain wasn't.
I also recently witnessed a discussion (was it libusb?)
where a suggestion for CMake build support was met with a clear number of
replies tending away from it, likely due to similar experience. Unfortunately.
I'm not familiar with that particular discussion, but the usual FUD goes
along the lines that people don't want yet another butt-ugly language.
Well, CMake language might not win a beauty contest, granted, but
ignoring the fact that the wide-spread autohell crap is a wild jumble of
POSIX-shell, Automake and, by far ugliest of all languages, M4. This
makes a total of 3 difficult to learn languages! So, replacing autohell
by CMake is actually a decrease by 2 languages, one of which must be the
most irritating and sadistic language ever invented (apart from
brainf*ck, that is).
Hopefully my story will enable people to see where there are problems
and how to approach any potential solutions.
I have to say that so far I'm quite happy with the sufficiently large
infrastructure that I was able to create, it's just that many areas
feel wanting (the entire BundleUtilities / install-time stuff
is an example of that, too).
I agree, the BundleUtilities need much more precise documentation.
Thanks,
Andreas Mohr
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Wed, Dec 22, 2010 at 12:57 PM, KC Jones kc.jo...@skype.net wrote: Feeling really uneasy about putting this out there, but here goes... I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and Linux (Ubuntu 10.04). The app depends on some libraries (Qt4.6 (no plugins) and a customized build of Poco). I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + Poco lib packaging) On Linux, I want a Debian package to install the Poco libs at a minimum along with my executable. Equivalent Windows installers will be needed someday. I've reviewed the docs at http://www.cmake.org/cmake/help/cmake-2-8-docs.html I've reviewed bits and pieces on the wiki: http://www.cmake.org/Wiki/BundleUtilitiesExample http://www.cmake.org/Wiki/CMake#CPack And I just don't seem to get it. I know this is very possible. I know this is my own problem, first and foremost. So I'm exposing myself to potential criticism here since RTFM and get a clue are probably the biggest part of fixing my problem. Im not really asking for specific help on my code - I might ask for that later. For now I just want to vent, hopefully in a constructive way. I just don't think that CPack documentation and examples as they currently are published are sufficient or effective. Neither do we: http://public.kitware.com/Bug/view.php?id=10067 A few suggestions: - More CPack example and tutorials would be very helpful. I see from archive searches that I'm not the first to suggest this. The Qt example is great, but the plugin support is overkill for most, and obfuscates much of the rest of the example. - A step-wise tutorial format that starts with a working build, adds install target support, then adds CPack code would help my addled brain. Presenting newbies like me with a fully baked end result is helpful, but somewhat hard to digest. - Separating the docs into different namespaces (Cmake, CPack, CTest...) might be more effective. I struggled a long while before finding the install command docs (which I continue to struggle with). The atomic layout of the docs obscures the module-level relationships. - A glossary, please. For instance bundle comes out of OS X, but now has some CMake-specific meaning for Linux and Win that I know is very important to me, but fully incomprehensible in my reading so far. Oh, and what are bundle keys? - More meta docs please. Somewhere in my stumbling I found a decent diagram about how the ExternalProject module works. I think it was on the wiki, but I can't find it now. I would die for something similar that shows what install does and how it integrates with CPack. Same goes for BudleUtilities and other modules I've yet to discover. As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always real (functional) bugs to be fixed. Perpetual questions: what's enough documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. One final comment, cmake is elegant in the extreme. I can see from some of the wiki pages about how install is a merge that canonically folds multiple precursors into one uber-powerful, uber-flexible silver bullet. Impressive I'm sure. But harder to grok. I'm not suggesting that this is a wrong choice. But it is a barrier to learning. Where there is this kind of folding of advanced features into basic operations, some care is needed to ensure the docs convey the basics clearly. WRT Cpack, what I find is that by merging it into CMake, the CPack code is declared one step away from where it is applied. The need for careful quoting in install(CODE ) blocks is a case in point. I'm sure this folding into a canonical, unified single CMakeLists.txt source is a good thing. But right now I feel like I'm learning Lisp again. Kind of mind blowing. Wishing I had some
Re: [CMake] CPack 101
On 23 December 2010 12:43, David Cole david.c...@kitware.com wrote: Neither do we: http://public.kitware.com/Bug/view.php?id=10067 As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always real (functional) bugs to be fixed. Perpetual questions: what's enough documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. I think the main problem is that you make it very hard for people to contribute. KDE and Homebrew (two other open-source projects I've written a lot of code for over the years) make this very easy. Kitware is great, you clearly write good code and have done a great job creating CMake and CPack. They are fantastic tools. However, I think until you are more encouraging of external developers you will struggle to make huge improvements to CMake. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. We (I hope I speak for all CMake devs, here) take no offense. We welcome discussion, always. The mailing list is OK but most people don't want to sign up to a mailing list and receive lots of emails that have nothing to do with them. I'm only signed up because I want to try and get some patches merged and was told that I should discuss things here rather than the bugtracker. I hope I don't cause any offense here either. I'm passionate about CMake because I like the tool and want to make it better. -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 1:43 PM, David Cole david.c...@kitware.com wrote: On Wed, Dec 22, 2010 at 12:57 PM, KC Jones kc.jo...@skype.net wrote: Feeling really uneasy about putting this out there, but here goes... I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and Linux (Ubuntu 10.04). The app depends on some libraries (Qt4.6 (no plugins) and a customized build of Poco). I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + Poco lib packaging) On Linux, I want a Debian package to install the Poco libs at a minimum along with my executable. Equivalent Windows installers will be needed someday. I've reviewed the docs at http://www.cmake.org/cmake/help/cmake-2-8-docs.html I've reviewed bits and pieces on the wiki: http://www.cmake.org/Wiki/BundleUtilitiesExample http://www.cmake.org/Wiki/CMake#CPack And I just don't seem to get it. I know this is very possible. I know this is my own problem, first and foremost. So I'm exposing myself to potential criticism here since RTFM and get a clue are probably the biggest part of fixing my problem. Im not really asking for specific help on my code - I might ask for that later. For now I just want to vent, hopefully in a constructive way. I just don't think that CPack documentation and examples as they currently are published are sufficient or effective. Neither do we: http://public.kitware.com/Bug/view.php?id=10067 A few suggestions: - More CPack example and tutorials would be very helpful. I see from archive searches that I'm not the first to suggest this. The Qt example is great, but the plugin support is overkill for most, and obfuscates much of the rest of the example. - A step-wise tutorial format that starts with a working build, adds install target support, then adds CPack code would help my addled brain. Presenting newbies like me with a fully baked end result is helpful, but somewhat hard to digest. - Separating the docs into different namespaces (Cmake, CPack, CTest...) might be more effective. I struggled a long while before finding the install command docs (which I continue to struggle with). The atomic layout of the docs obscures the module-level relationships. - A glossary, please. For instance bundle comes out of OS X, but now has some CMake-specific meaning for Linux and Win that I know is very important to me, but fully incomprehensible in my reading so far. Oh, and what are bundle keys? - More meta docs please. Somewhere in my stumbling I found a decent diagram about how the ExternalProject module works. I think it was on the wiki, but I can't find it now. I would die for something similar that shows what install does and how it integrates with CPack. Same goes for BudleUtilities and other modules I've yet to discover. As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always real (functional) bugs to be fixed. Perpetual questions: what's enough documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. How about a search for the mailinglist archives? One final comment, cmake is elegant in the extreme. I can see from some of the wiki pages about how install is a merge that canonically folds multiple precursors into one uber-powerful, uber-flexible silver bullet. Impressive I'm sure. But harder to grok. I'm not suggesting that this is a wrong choice. But it is a barrier to learning. Where there is this kind of folding of advanced features into basic operations, some care is needed to ensure the docs convey the basics clearly. WRT Cpack, what I find is that by merging it into CMake, the CPack code is declared one step away from where it is applied. The need for careful quoting in install(CODE ) blocks is a case in point. I'm sure this folding into a
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 7:58 AM, Mike McQuaid m...@mikemcquaid.com wrote: On 23 December 2010 12:43, David Cole david.c...@kitware.com wrote: Neither do we: http://public.kitware.com/Bug/view.php?id=10067 As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always real (functional) bugs to be fixed. Perpetual questions: what's enough documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. I think the main problem is that you make it very hard for people to contribute. KDE and Homebrew (two other open-source projects I've written a lot of code for over the years) make this very easy. How do we make it very hard? What about KDE and Homebrew make this very easy? Specifics, please. Kitware is great, you clearly write good code and have done a great job creating CMake and CPack. They are fantastic tools. However, I think until you are more encouraging of external developers you will struggle to make huge improvements to CMake. Thank you. Even with more external developers, I think we'll struggle -- that would just be a different sort of struggle. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. We (I hope I speak for all CMake devs, here) take no offense. We welcome discussion, always. The mailing list is OK but most people don't want to sign up to a mailing list and receive lots of emails that have nothing to do with them. I'm only signed up because I want to try and get some patches merged and was told that I should discuss things here rather than the bugtracker. I hope I don't cause any offense here either. I'm passionate about CMake because I like the tool and want to make it better. Again, let me stress, no offense taken. There is no way you can offend me, unless you start calling me names for no reason. Reasonable discussion always welcome. Thx, David -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 8:23 AM, Johan Björk p...@spotify.com wrote: On Thu, Dec 23, 2010 at 1:43 PM, David Cole david.c...@kitware.comwrote: On Wed, Dec 22, 2010 at 12:57 PM, KC Jones kc.jo...@skype.net wrote: Feeling really uneasy about putting this out there, but here goes... I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and Linux (Ubuntu 10.04). The app depends on some libraries (Qt4.6 (no plugins) and a customized build of Poco). I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + Poco lib packaging) On Linux, I want a Debian package to install the Poco libs at a minimum along with my executable. Equivalent Windows installers will be needed someday. I've reviewed the docs at http://www.cmake.org/cmake/help/cmake-2-8-docs.html I've reviewed bits and pieces on the wiki: http://www.cmake.org/Wiki/BundleUtilitiesExample http://www.cmake.org/Wiki/CMake#CPack And I just don't seem to get it. I know this is very possible. I know this is my own problem, first and foremost. So I'm exposing myself to potential criticism here since RTFM and get a clue are probably the biggest part of fixing my problem. Im not really asking for specific help on my code - I might ask for that later. For now I just want to vent, hopefully in a constructive way. I just don't think that CPack documentation and examples as they currently are published are sufficient or effective. Neither do we: http://public.kitware.com/Bug/view.php?id=10067 A few suggestions: - More CPack example and tutorials would be very helpful. I see from archive searches that I'm not the first to suggest this. The Qt example is great, but the plugin support is overkill for most, and obfuscates much of the rest of the example. - A step-wise tutorial format that starts with a working build, adds install target support, then adds CPack code would help my addled brain. Presenting newbies like me with a fully baked end result is helpful, but somewhat hard to digest. - Separating the docs into different namespaces (Cmake, CPack, CTest...) might be more effective. I struggled a long while before finding the install command docs (which I continue to struggle with). The atomic layout of the docs obscures the module-level relationships. - A glossary, please. For instance bundle comes out of OS X, but now has some CMake-specific meaning for Linux and Win that I know is very important to me, but fully incomprehensible in my reading so far. Oh, and what are bundle keys? - More meta docs please. Somewhere in my stumbling I found a decent diagram about how the ExternalProject module works. I think it was on the wiki, but I can't find it now. I would die for something similar that shows what install does and how it integrates with CPack. Same goes for BudleUtilities and other modules I've yet to discover. As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always real (functional) bugs to be fixed. Perpetual questions: what's enough documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. How about a search for the mailinglist archives? A typical google search about CMake stuff yields mailing list discussions as the top hits the vast majority of the time. If you want to search *just* the mailing list archives, use: site:http://www.cmake.org/pipermail/cmake I really, really don't think we can provide you with a better search experience than Google. Just sayin'... Thx, David One final comment, cmake is elegant in the extreme. I can see from some of the wiki pages about how install is a merge that canonically folds multiple precursors into one uber-powerful, uber-flexible silver bullet. Impressive I'm sure. But harder to grok. I'm not suggesting that this is a wrong
Re: [CMake] CPack 101
On 23 December 2010 13:24, David Cole david.c...@kitware.com wrote: How do we make it very hard? What about KDE and Homebrew make this very easy? Specifics, please. Firstly, http://producingoss.com/ is a great read. Specifically though, Homebrew is pretty much the golden child of encouraging external contribution. We're the most forked repo on Github, the 6th most watched and have had 719 code contributors in about a year and a half of existing. We've managed this with only 4 people with commit access, all of whom have full-time jobs in the industry working on other projects. I think Github and DVCS really allows you to scale well. If you publish decent guidelines for how people can contribute and use e.g. pull requests on Github or similar Git mechanisms then you can have incredibly quick workflows for viewing, mergeing, testing and pushing user code. I have an alias bpi in my shell which downloads from a pull request or user repository commit on Github, applies it to my local repository, shows me the changes and installs the relevant changes packages. Once I type git push this is now shared with everyone using the project. I think for you guys general guidelines on what patches would/wouldn't be accepted would be a good start. Documentation of your coding standards and what I should do to test my work before submitting it would help too. I can guess a fair amount because I've contributed to a lot of open-source projects but others might not do the same. I think the main thing that I find lacking here though is responsiveness to suggestions. When I make one, I need to keep poking again and again until I receive I response. Other things include specific code review of patches and a quick this functionality would/wouldn't be accepted when suggestions are made so I know whether to work on it or not. I think using Git/Github in your workflow could help with part of this but a certain amount will need to be responding to users, either through your current bug tracker, a better one or Github's issue tracker. Another option that might help is a cmake-dev mailing list that is only for discussing development issues rather than users seeking help. Just a few ideas for you. Hopefully some of them are useful. I'm more than willing to discuss this in further depth, either here, personal mail or at an open-source conference (next one I'll definitely be at will be the KDE one in Berlin 2011). Thank you. Even with more external developers, I think we'll struggle -- that would just be a different sort of struggle. Sure, it will probably involve more reviewing/mentoring but less code writing. Again, let me stress, no offense taken. There is no way you can offend me, unless you start calling me names for no reason. Reasonable discussion always welcome. So can I call you names as long as I have a good reason? ;) -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/23/2010 8:44 AM, Mike McQuaid wrote: On 23 December 2010 13:24, David Coledavid.c...@kitware.com wrote: How do we make it very hard? What about KDE and Homebrew make this very easy? Specifics, please. I think for you guys general guidelines on what patches would/wouldn't be accepted would be a good start. Documentation of your coding standards and what I should do to test my work before submitting it would help too. I can guess a fair amount because I've contributed to a lot of open-source projects but others might not do the same. I think the main thing that I find lacking here though is responsiveness to suggestions. When I make one, I need to keep poking again and again until I receive I response. Other things include specific code review of patches and a quick this functionality would/wouldn't be accepted when suggestions are made so I know whether to work on it or not. I think using Git/Github in your workflow could help with part of this but a certain amount will need to be responding to users, either through your current bug tracker, a better one or Github's issue tracker. Another option that might help is a cmake-dev mailing list that is only for discussing development issues rather than users seeking help. Something like this perhaps: http://www.cmake.org/cmake/help/mailing.html http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers The way I see it, there are two types of contributions. 1. You have already written some code that does something you need for your project. 2. You have a suggestion for a change that you would like to see but have not done. These two cases are treated differently. Here is the workflow I would would like to see for them: 1. you have some code. The biggest thing that slows down adoption of new code in CMake is lack of testing. New features that are not tested, are not welcome into CMake. If the code has a CMake test and there is good dashboard coverage for the test, then the code will be adopted much quicker. The code can be done on github or gitorious.org, or just a patch attached to a bug entry in the CMake bug tracker. If a cmake developer can just merge in the code, and run ctest to test the new code, it makes it very easy to commit. 2. You have a suggestion for a change but no code. I think there are two sub-cases for this as well: A. You are willing to write the code yourself. B. You think that someone else should write it for you. For A, you would want to get buy in from the developers and community before starting the code. For this the cmake-developers mailing list would be the place to start. Although, sometimes it might make sense to float the idea on the cmake mailing list first to see what the community things, and then use the developers list for implementation details. For B, you have to do a pretty good sales job for the work to be done. You are basically asking for a handout. Kitware does not directly invest in CMake, new features developed by Kitware come from Kitware customers requesting them. So, you can hire Kitware (become a customer), or if your suggestion lines up with the needs of an existing customer, you might get lucky. Of course Kitware people are not the only ones developing CMake, you might be able to convince someone else to do the work. Either way, this is the hardest type of change to have made. In summary, Kitware and the CMake developers outside Kitware have been working on being more inclusive. We realize that our process needs to include more of the community. Recently we have made several changes in order to include more outside help on the CMake project. Those changes are as follows: 1. We moved to git 2. We moved to a quarterly release schedule. 3. After each release we send out and email to the cmake and cmake-developers list, and ask for people to suggest the things they would like to see in the next release. Here is the current list: http://public.kitware.com/Bug/roadmap_page.php. Next release is scheduled for Jan. 10. 4. We have directed all new bugs on the bug tracker to the cmake-developers list. This allows all developers to see new issues as they come in. 5. We have made an effort to clean up old stuff in the bug tracker. So, if you have time that you want to spend on CMake development, join the cmake-developers mailing list. Write some tested, documented code and contribute it. Thanks. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
Hi Mike and all, On Thu, Dec 23, 2010 at 21:58, Mike McQuaid m...@mikemcquaid.com wrote: On 23 December 2010 12:43, David Cole david.c...@kitware.com wrote: I think the main problem is that you make it very hard for people to contribute. KDE and Homebrew (two other open-source projects I've written a lot of code for over the years) make this very easy. Kitware is great, you clearly write good code and have done a great job creating CMake and CPack. They are fantastic tools. However, I think until you are more encouraging of external developers you will struggle to make huge improvements to CMake. As only a casual user of CMake, I'm hesitant to enter this kind of thread, but a comment like the above is difficult to ignore. :-) IMHO, the comparison between KDE and CMake is a bit unfair. KDE is visible to many people, both developers and users, while CMake is known by only developers. Also, it is known that CMake is developed by Kitware; this is quite different from KDE which relies on a very large international community. So, combining these two reasons, it is not so surprising that the management of how KDE is developed is more advanced. Yes, they are both open-source, but two software can be both open-source but still be run differently. It isn't necessary for one open-source software to be managed similar to another one. And I think (without knowing the actual numbers) that the code to KDE is larger than CMake? Personally, the help I've seen on this mailing list and in the mailing list archives is great and while there may be room for improvement, I guess it can happen in time. The mailing list is OK but most people don't want to sign up to a mailing list and receive lots of emails that have nothing to do with them. I'm only signed up because I want to try and get some patches merged and was told that I should discuss things here rather than the bugtracker. I hope I don't cause any offense here either. I'm passionate about CMake because I like the tool and want to make it better. Someone else has talked about using Google on the archives. An often ignored point is that thanks to Google, you can contribute to the documentation just by writing a web page. If it is useful and gets linked by others, etc., then the right keywords will make your web page appear on the first page of Google's results. Some of the help I've got on CMake, CPack, etc. are on non-cmake pages, actually. Of course, if these pages are wrong, then the error propagates... But if it is useful, I guess Kitware developers will be happy to include it in the Wiki at least? Ray ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/23/2010 9:59 AM, Mike McQuaid wrote: A few questions: What platforms does it need to be tested on? At least one. The important thing is that it actually has a test, that will be run with make test on CMake after the code is merged into CMake. The dashboards will take care of testing it on platforms you don't have. We are also working on some interesting stuff in this area as well: http://www.kitware.com/products/html/TheCDashHomeCloud.html What branch should you base it off? master http://www.cmake.org/Wiki/CMake/Git#Branches There is also this article that we did on DVCS that might give some insight on our thoughts: http://www.kitware.com/products/html/DistributedVersionControlTheFutureOfHistory.html Great, I think I understand how to do that a bit better now. It would be great if the contents of your email above was included here: http://www.cmake.org/cmake/project/getinvolved.html and also possibly on your Github/Gitorious pages. Yes, much of this is new stuff, so it has not yet made it to that page yet. I have been thinking about the issues you brought up for some time now, and have not yet written them down. Thanks for the comprehensive reply and sorry for any criticism from my misunderstandings above. Thanks for the post, I am glad that it is more of a documentation bug than a process issue. Being on the inside, I of course know what I and the other CMake developers are thinking. It is easy to fall into the trap of thinking that everyone knows what you know... Although sometimes having stuff on web pages is not enough (existence of cmake-developers case in point...). However, the how to get code into CMake is not documented anywhere yet Thanks, and I look forward to you contributions! -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
Thanks for your comments and questions. May we quote you on that? (cmake is
elegant in the extreme ... great tool)
Of course. Since all the code I work with is published on multiple OSes, cmake
is a godsend. I'm actively working on replacing as much of our legacy build
methods with cmake solutions. The cmake basics have come relatively easily to
me. CPack is another story.
Once I get through to the end of this tunnel and have learned CPack well
enough, I hope to be in a position to offer more constructive contributions to
easing this learning curve. But, like the problem you describe where there is
never time for docs and never enough docs, the reality is that when my builds
are humming, there will be other tasks waiting -- and the task of 'giving back
to the community' somehow never rises to the top of the stack.
One thought that is jangling around in my head right now:
WRT install(CODE ...) quoting, would it be useful to support the ruby here
document syntax?
install(CODE xxx
include(BundleUtilities)
fixup_bundle(${APPS} ${QTPLUGINS} ${DIRS})
xxx
COMPONENT Runtime)
Or is variable substitution at cmake execution time more the rule than the
exception?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 3:59 PM, KC Jones kc.jo...@skype.net wrote:
Thanks for your comments and questions. May we quote you on that? (cmake
is elegant in the extreme ... great tool)
Of course. Since all the code I work with is published on multiple OSes,
cmake is a godsend. I'm actively working on replacing as much of our legacy
build methods with cmake solutions. The cmake basics have come relatively
easily to me. CPack is another story.
Once I get through to the end of this tunnel and have learned CPack well
enough, I hope to be in a position to offer more constructive contributions
to easing this learning curve. But, like the problem you describe where
there is never time for docs and never enough docs, the reality is that when
my builds are humming, there will be other tasks waiting -- and the task of
'giving back to the community' somehow never rises to the top of the stack.
One thought that is jangling around in my head right now:
WRT install(CODE ...) quoting, would it be useful to support the ruby here
document syntax?
install(CODE xxx
include(BundleUtilities)
fixup_bundle(${APPS} ${QTPLUGINS} ${DIRS})
xxx
COMPONENT Runtime)
Or is variable substitution at cmake execution time more the rule than the
exception?
I think we've somehow favored install(CODE way too much over install(SCRIPT
in the examples that we *do* have.
If there are serious readability problems with any install(CODE chunk
because of excessive escaping required, it should be in its own file where
it does not need to be escaped, (even if it's only 1, 2 or 3 lines), and
then install(SCRIPT can simply include the file in the very same place where
the CODE would have been generated.
So have a file, InstallBundle.cmake whose contents are:
include(BundleUtilities)
fixup_bundle(${APPS} ${QTPLUGINS} ${DIRS})
And then use:
install(SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/InstallBundle.cmake COMPONENT
Runtime)
Much easier on the eyes, much nicer in every respect except there's one
extra file in your source tree now. Small price to pay for readability and
future maintainability...
HTH,
David
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 23 December 2010 22:05, David Cole david.c...@kitware.com wrote: Much easier on the eyes, much nicer in every respect except there's one extra file in your source tree now. Small price to pay for readability and future maintainability... Agreed. I think what would be even nicer would be to be able to do common tasks using INSTALL(SOMETHING) to e.g. run fixup for you without having to use another script or INSTALL(CODE). -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-requ...@cmake.org wrote:
Date: Wed, 22 Dec 2010 09:57:11 -0800
From: KC Jones kc.jo...@skype.net
Subject: [CMake] CPack 101
And I just don't seem to get it. I know this is very possible. I know this
is my own problem, first and foremost. So I'm exposing myself to potential
criticism here since RTFM and get a clue are probably the biggest part of
fixing my problem. Im not really asking for specific help on my code - I
might ask for that later. For now I just want to vent, hopefully in a
constructive way.
I have nothing to add about your particular description, but let me just
say that I can fully relate to how you feel, given that I hit a truly-WTF
situation just yesterday, too:
convert (imagemagick) appears to have incompatible versions which write
to either file.xpm.0 or file-0.xpm (and there's no option to specify
a specific file name prefix/format for icon series).
So, to convert an icon file, add an add_custom_command().
The problem then becomes how to know which file to choose
for subsequent COMMAND lines,
given that EITHER the one OR the other output file naming
is available after conversion.
- there's no cmake -E rename available (perhaps for reasons of build rule
atomicity)
- trying to use cmake -E copy will FAIL for one of the two file name
candidates, causing target processing to ABORT (thus cmake -E rename
wouldn't be better ;)
- trying to detect file existence (e.g. via stat) within
add_custom_command() processing is not possible either (how to branch
based on the result? ok, perhaps doable via a chain of targets...)
- I settled on COMMAND sh -c '(mv -f src_a dest || mv -f src_b dest)',
however that also is very problematic since sh -c is for
single-command execution, not for composite commands
(and, indeed, thus will work on RHEL5 and readily fail on Mac OS X)
- so, decided to use a file(WRITE ...) to actually on-demand-write the
entire add_custom_command() content as a shell script
(which actually seems more suitable since it elegantly merges multiple
COMMAND lines into a simple shell script)
- no go, since file(WRITE) always uses Windows newlines (there's no builtin
dos2unix support in CMake nor a support module which provides nicely
abstracted access to dos2unix, tofrodos, tr or other suitable tools,
nor an - admittedly architecturally not really desireable - hard-coded
builtin way
for file(WRITE) to specify that one wants UNIX line feeds)
- no go, since file(WRITE) result has wrong permissions (that one could be fixed
via some additional magic involving configure_file() etc.)
- so, perhaps use an existing shell script template via
configure_file(), then adjust permissions?
- that's impossible due to using that @!#$^#3)+...@! RCS abomination called VSS
(yes, in TWO-THOUSAND-AND-TEN, still!) via SOS which is unable
to provide any support for line feeds and permissions
(but this admittedly is also a somewhat more complex topic in e.g. git or SVN)
- could have _manually_ added in configuration for dos2unix functionality
(and in fact I'm using it somewhere else already),
but this SHOULD NOT BE NEEDED (we _are_ on a UNIX platform and thus
there _should_ be some builtin aid for that) and thus I bailed at adding
complicated support lines for that
- finally, due to having to find a solution due to the Mac OS X issue
mentioned above, chose to use
COMMAND sh -c 'cat file.xpm.0 file-0.xpm result.xpm'
- cat FAILED due to one of the two files not being available
(and cat -f is not available.)
- thus used the laughably incredible workaround of
COMMAND ${CMAKE_COMMAND} -E touch file.xpm.0
COMMAND ${CMAKE_COMMAND} -E touch file-0.xpm
COMMAND sh -c 'cat file.xpm.0 file-0.xpm result.xpm'
That's 13 items of descriptions of failure (and I'm sure I forgot to
list some other failed avenues which I had been thinking about).
YUCK.
I don't know what the perfect answer here is (or possibly I'm just blind
for it?), but I know for certain that a simple Makefile rule
would have a lot more flexibility / simplicity,
and this simplicity is what CMake should strive to match
while keeping its current very nice full generator/platform abstraction.
Yes, of course that's hard, but IMHO the above story clearly shows that
_something_ appears to be much too involved about it, since there was
exactly no help at all anywhere, to defuse the situation to enable me
to reach a satisfying result. IOW implementation pressure due to
multiple CMake constraints is __MUCH__ too high, e.g. in the realms of line
feeds / permissions / symlinks especially (multiple discussion threads on the
internet about this).
To put it simply, I was just not happy the entire time while
trying to implement this and not finding any satisfying (well-crafted) solution,
only ugly, very bad or semi-failing workarounds.
That kind of work should be _fun_, especially when it then results in a
nicely working and fully automated
