[CMake] EXECUTE_PROCESS too good at running programs

[Brandon J. Van Every]

Brad King wrote:
> Brandon J. Van Every wrote:
>   
>> Brad King wrote:
>>     
>>> Brandon J. Van Every wrote:
>>>   
>>>       
>>>> I explained the situation pretty clearly, I thought. 
>>>> E:\msys\1.0\bin\makefile does *NOT* run under a Windows command prompt. 
>>>> It's not supposed to.  As I said before, there's a comment at the top of
>>>> the binary that says it's not supposed to.  Just to reiterate again in
>>>> case there's any doubt:
>>>>
>>>> E:\msys\1.0\bin>dir makeinfo
>>>> Volume in drive E is MONDRIAN
>>>> Volume Serial Number is 9CA0-CADF
>>>>
>>>> Directory of E:\msys\1.0\bin
>>>>
>>>> 04/30/2004  11:15p             180,224 makeinfo
>>>>               1 File(s)        180,224 bytes
>>>>               0 Dir(s)  11,499,749,376 bytes free
>>>>
>>>> E:\msys\1.0\bin>cmd
>>>> Microsoft Windows 2000 [Version 5.00.2195]
>>>> (C) Copyright 1985-2000 Microsoft Corp.
>>>>
>>>> E:\msys\1.0\bin>makeinfo
>>>> 'makeinfo' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>>     
>>>>         
>>> I don't think your test is reliable.  My MSYS has a makeinfo.exe and it
>>> runs under a windows shell.
>>>   
>>>       
>> My test is plenty reliable.  I have ***makeinfo***, not makeinfo.exe. 
>> Please read *ALL* the details of my post.  There are ~30 tools in
>> E:\msys\1.0\bin that do not have .exe suffixes, run fine under a MSYS
>> shell, and are not intended to be run under anything but a MSYS shell. 
>> EXECUTE_PROCESS is finding a way to run them.  My wild-assed-guess as to
>> explanation, is that it execs arbitrarily named files, and does not
>> check whether the filename is valid for a Windows command prompt.  These
>> MSYS tools are probably valid apps in some Windows-native sense, but not
>> to a Windows command prompt.
>>     
>
> I did read your entire post.  I'm saying that on my system makeinfo will
> run under VS.  Your test is not reliable because it does not try running
> it under the build environment.
>   

To reiterate, you have "makeinfo.exe", not "makeinfo".  I believe that 
EXECUTE_PROCESS does not pay attention to the necessity of .exe, .cmd, 
and .bat suffixes under VS71 IDE shells.  I believe that EXECUTE_PROCESS 
should be running in a manner compatible with its generator.  Otherwise, 
what use is a generator?

>   
>> That is a (tedious) workaround, but I still say the behavior of
>> EXECUTE_PROCESS is bugged.  I don't think anyone should have to write an
>> OS-specific C coded exec wrapper just to determine if "makeinfo"
>> actually works under the build environment.
>>     
>
> There is absolutely no way EXECUTE_PROCESS can know exactly how the
> build environment will run a tool.

It can certainly know that a VS71 build environment requires .exe, .cmd, 
or .bat suffixes to run anything at all.

>   This is the purpose of try-compiles.
>   You don't need to write any C code, just a small CMakeLists.txt file
> that has a custom target to try running makeinfo.  It is not a
> work-around, but the right way to do it.
>
>   

Ok, the CMake 2.4.2 documentation for the projectName version of 
TRY_COMPILE is only 3 short sentences.  IIUYC, you are saying I'm going 
to have to write a CMakeLists.txt wrapper, and a subdirectory, for each 
and every tool like "makeinfo," if I want to prove that they work in the 
build.  This strikes me as bureaucratic.  Determining whether found 
tools actually work is an exceedingly common operation, and the sort of 
thing that ./configure does routinely without much hassle.  Of course, 
./configure is always using /bin/sh.

Personally, I think having EXEC_PROCESS pay attention to the basic 
expectations of a build environment, is a better solution.  It already 
has all the input and output parameters that one would expect.  It has 
much more verbose documentation about success and failure codes, leading 
CMake developers to believe that this is how they should try stuff.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060721/38badcc1/attachment.htm