[CMake] Re: TRY_COMPILE painful for tool testing

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> Brandon J. Van Every wrote:
>> William A. Hoffman wrote:
>>> At 08:17 AM 7/22/2006, Brad King wrote:
>>>   
>>>>
>>>> You can create a macro to wrap this all up.
>>> Regardless of the documentation, try-compile and not exec_process is what is supposed
>>> to be used for system introspection.
>>>   
>>
>
> I am finding it nearly impossible to write such a macro in practice.  
> The problem is that a custom COMMAND has no understanding of native 
> CMake paths.  So I must convert the paths to a native format, and 
> FILE(TO_NATIVE_PATH ...) does not properly escape and quote the path 
> for use by COMMAND.  Also, the COMMAND string needs to be saved 
> somehow.  It needs to be used by TRY_COMPILE, and again by my 
> CMakeLists.txt, so that I'm doing exactly the same thing each time.  
> Saving the string is problematic because passing the string around 
> tends to destroy the quoting.


I cannot find any well-defined point of control for escaping backslashes 
or quotes in strings and macros.  Different levels of CMake are 
consuming them differently.  This is preventing COMMAND from being 
usable in any kind of portable manner.  Actually it makes me wonder why 
I have ever been able to use it portably thus far.  I have all sorts of 
COMMAND statements to drive the Chicken compiler.  I believe they work 
because all the commands are of the form

  COMMAND ${CURRENT_CHICKEN} ...

CURRENT_CHICKEN is determined either by FIND_PROGRAM, direct user entry 
in CMakeSetup / CCMake, or GET_TARGET_PROPERTY(... LOCATION) during the 
bootstrap.  So it seems all these points of control work just fine and 
deliver correct native paths.  Also I have never tried to pass 
CURRENT_CHICKEN around through multiple levels of CMake.  It is a global 
variable and is used implicitly by my macros; it is never passed as a 
macro argument.

I think the result is, quotes and backslashes cannot be reliably escaped 
with respect to macro wrappers for ADD_CUSTOM_TARGET.  Thus it is not 
possible to write a macro that will TRY_COMPILE an arbitrary COMMAND.

So the feature that I would like, is a TRY_COMMAND that produces, in the 
native shell, whatever you actually give it for command arguments.  The 
interface should be:

  TRY_COMMAND(RESULT_VAR <arbitrary commands with quotes, backslashes, 
semicolons, and whitespace>)

No intermediate layers of escape massaging to mess things up.  It would 
also need to take ${VARIABLES} and substitute them properly.  It should 
handle "${VARIABLES}" properly, i.e. turn a CMake list into a string, 
and not see the quotes as the termination of the command.  I'm inclined 
to think this TRY_COMMAND cannot be accomplished in CMake script.  At 
any rate, I need feedback on the problem before I'll have the patience 
to try again.


Cheers,
Brandon Van Every


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060920/e0cc2a24/attachment.html