Fixes for finding png crush executable

[colincornaby]

I'm not sure why this is required or how the fix improves things - but the part of the CMake script that finds pngcrush has been failing on some of my Macs. I'm not sure why - the Mac that I am seeing this on is running the latest version of CMake.

These changes to the script seem to make things work.

If anyone has a CMake perspective on why this is going on or why the fix works - that would be appreciated.

[dpogue]

We need to keep the space at the end, because it appends other arguments to the string without a leading space

[colincornaby]

I believe that causes things to fail again - but lemme double check.

[colincornaby]

Does actually seem to work on this machine even with the space. I'll make the edit.

[colincornaby]

I take it back. The space is once again not working.

Showing All Messages
FileNotFoundError: [Errno 2] No such file or directory: '/Applications/Xcode.app/Contents/Developer/usr/bin/pngcrush '

See how the space is incorporated into the file path?

As I was researching this I found some information that CMake does not do simple string work very well and will try to automatically escape things or encapsulate them in quotes. That seems like this is what is happening here but I don't know enough to make a good guess as to what the best fix is.

[dgelessus]

Can you print out the value of PNGCRUSH_EXECUTABLE from inside the CMake script to check if perhaps the space is already there in the variable and not caused by the argument building? In my experience, CMake usually handles string quoting/escaping very well - so if the argument passed to Python has a trailing space, that probably means that there's an actual space at the end of the variable value.

I wonder if it's a problem that OPTIMIZE_ARGUMENT is a single string of space-separated arguments, not a proper CMake list. Does the behavior change if you replace string(APPEND ...) with list(APPEND ...) and make sure there are no spaces inside the quoted strings? (For that to work, you might have to pass COMMAND_EXPAND_LISTS to add_custom_command, but I'm not sure...)

[Hoikas]

I wonder if it's a problem that OPTIMIZE_ARGUMENT is a single string of space-separated arguments, not a proper CMake list.

This is correct. The problem here is that we're crossing wires a bit. CMake really only has one data type - string. Lists, booleans, and such are really just specially formatted strings. The problem here is that we're mixing a command line argument string into a list of arguments.

To illustrate, this is a string with the contents Hello World

set(hello "Hello World")

These are a list with the items Hello and World

set(hello Hello World)
set(hello Hello;World)

when printed, this will appear as Hello;World.

The variable OPTIMIZE_ARGUMENT is being reproduced unquoted, which is a hint that we want to retain magical datatypes eg lists. Unfortunately, the code populating the variable is using string functions, which doesn't make the semicolon separated list. So, our arguments wind up all goofy python.exe;makeres.py;--render;--pagkage;--pngcrush pngcrush.exe --brute;-i;/external;-w;/bin;-o;/bin. Using list commands will properly populate OPTIMIZE_ARGUMENT as a list.

[colincornaby]

Proposed changes seem to work fine on my Mac.