[CMake] CPack 101

[Michael Wild]

On 12/22/2010 11:24 PM, Andreas Mohr wrote:
> 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).

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