[CMake] CPack 101

[Andreas Mohr]

On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-request at cmake.org wrote:
> Date: Wed, 22 Dec 2010 09:57:11 -0800
> From: KC Jones <kc.jones at 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