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 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. 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). Thanks, Andreas Mohr _______________________________________________ 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