<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brandon J. Van Every wrote:
<blockquote cite="mid45118772.1020900@gmail.com" type="cite">
<meta http-equiv="Context-Type"
content="text/html; charset=ISO-8859-1">
Brandon J. Van Every wrote:
<blockquote cite="mid44C2562A.9030500@gmail.com" type="cite">
<title></title>
William A. Hoffman wrote:
<blockquote
cite="mid6.2.0.14.2.20060722084854.0844e320@pop.nycap.rr.com"
type="cite">
<pre>At 08:17 AM 7/22/2006, Brad King wrote:
</pre>
<blockquote type="cite"><br>
<pre>You can create a macro to wrap this all up.</pre>
</blockquote>
<pre>Regardless of the documentation, try-compile and not exec_process is what is supposed
to be used for system introspection.
</pre>
</blockquote>
<br>
</blockquote>
<br>
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. <br>
</blockquote>
<br>
<br>
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<br>
<br>
COMMAND ${CURRENT_CHICKEN} ...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
TRY_COMMAND(RESULT_VAR <arbitrary commands with quotes,
backslashes, semicolons, and whitespace>)<br>
<br>
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.<br>
<br>
<br>
Cheers,<br>
Brandon Van Every<br>
<br>
<br>
</body>
</html>