[CMake] EXECUTE_PROCESS too good at running programs

Brandon J. Van Every bvanevery at gmail.com
Fri Jul 21 13:23:16 EDT 2006


David Cole wrote:
> If you have the MSYS tools in your Windows system path and you can run 
> makeinfo from a Windows "cmd" prompt then it should also be able to 
> work from Visual Studio. 

Please reread.  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.

> If you click on "Start > Run" and type "cmd" and hit enter, can you 
> run makeinfo from that "raw Windows cmd prompt"?
>
> The flaw here is in the mismatch between Visual Studio's handling of 
> the PATH and your expectation that it should be in sync with your 
> actual current PATH env value.

No, the flaw is that EXECUTE_PROCESS is finding a way to run a non-DOS 
program and succeeding at it.  It is as though it invokes whatever shell 
is necessary to run the app, or just happens to have MSYS linkage, or it 
runs a Unixy shell and makeinfo happens to like that.  Or something 
similarly bizzare.  Visual Studio cannot ever run this program; as far 
as it is concerned, it is not a valid program.

Perhaps makeinfo really is an exe, but by standard Windows command 
prompt convention, files must end in .exe or .cmd or .bat to be 
recognized as apps.  Perhaps EXECUTE_PROCESS has no such limitation and 
merrily execs it.  My point is that CMake should do what the target 
compiler does.  VS71 IDE projects never run under shells that can 
execute arbitrarily named apps.


> VS copies the PATH at Visual Studio install time and *never* updates 
> it again except by user direction...
>
> You can try adding "E:\msys\1.0\bin" to the end of the list of Visual 
> Studio paths under "Tools > Options > Projects > VC++ Directories > 
> Win32 / Executable Files" -- what you'll see in there is a list of VS 
> directories first, followed by a snapshot copy of the PATH from when 
> you installed VS.
>
> Really, VS is just helping you out... You just didn't know you 
> preferred "stability" over "up-to-date-ness"... :-)
>

Just to belabor the point even further, I added E:\msys\1.0\bin to the 
VS path as above, and of course it changes nothing.  And now I'm 
removing it again, so that it doesn't screw with my builds in other 
weird unanticipated ways.


Cheers,
Brandon

>
>
> Brandon J. Van Every wrote:
>
>> I'm using CMake 2.4.2 and using the Visual Studio .NET 2003 
>> generator.  When I do
>> FIND_PROGRAM(MAKEINFO_EXE NAMES makeinfo)
>> it picks up my MSYS makeinfo, because I have my MSYS tools in my 
>> Windows system path.  The exact filename found, as reported by 
>> CMakeCache.txt, is
>>
>> MAKEINFO_EXE:FILEPATH=E:/msys/1.0/bin/makeinfo
>>
>> Most of the MSYS tools have .exe suffixes and will run under a plain 
>> Windows command prompt.  Some, however, do not have .exe suffixes and 
>> are not meant to run outside of MSYS.  Such is makeinfo.  When I open 
>> makeinfo under a text editor, I see that it is some kind of binary, 
>> and it has a string near the top of it that says, "This program 
>> cannot be run in DOS mode."
>>
>> EXECUTE_PROCESS proves to be exceptionally clever at getting makeinfo 
>> to run.  Too clever.  Somehow, it gets it to run, and returns a 
>> success code.  Under a VS71 generator, it should be flunking it.  
>> Because it certainly doesn't work in the resultant VS71 .sln file, 
>> which presumably uses a 'DOS' mode to execute custom targets.
>>
>> My mighty CMakeLists.txt:
>>
>> FIND_PROGRAM(MAKEINFO_EXE NAMES makeinfo)
>> IF(MAKEINFO_EXE)
>>
>>  MESSAGE("Testing whether makeinfo returns error codes.")
>>  EXECUTE_PROCESS(COMMAND ${MAKEINFO_EXE} --idiot
>>    RESULT_VARIABLE MAKEINFO_FAILED)
>>  IF(MAKEINFO_FAILED)
>>    MESSAGE("makeinfo returns an error code when given bogus arguments.")
>>  ELSE(MAKEINFO_FAILED)
>>    MESSAGE("makeinfo returns success even with bogus arguments.")
>>  ENDIF(MAKEINFO_FAILED)
>>
>>  MESSAGE("Testing whether makeinfo actually works.")
>>  EXECUTE_PROCESS(COMMAND ${MAKEINFO_EXE} --version
>>    RESULT_VARIABLE MAKEINFO_FAILED)
>>  IF(MAKEINFO_FAILED)
>>    MESSAGE("makeinfo does not work")
>>    ADD_CUSTOM_TARGET(info
>>      COMMAND ${CMAKE_COMMAND} -E echo makeinfo does not work)
>>  ELSE(MAKEINFO_FAILED)
>>    MESSAGE("makeinfo works")
>>    ADD_CUSTOM_TARGET(info
>>      COMMAND ${MAKEINFO_EXE} --version)
>>  ENDIF(MAKEINFO_FAILED)
>>
>> ELSE(MAKEINFO_EXE)
>>  MESSAGE("makeinfo not available")
>>  ADD_CUSTOM_TARGET(info
>>    COMMAND ${CMAKE_COMMAND} -E echo makeinfo not available)
>> ENDIF(MAKEINFO_EXE)
>>
>>
>> My results in CMakeSetup:
>>
>> Testing whether makeinfo returns error codes.
>> makeinfo returns an error code when given bogus arguments.
>> Testing whether makeinfo actually works.
>> makeinfo works
>>
>>
>> It fails in VS71 thusly:
>>
>> ------ Build started: Project: info, Configuration: Debug Win32 ------
>>
>> Performing Post-Build Event...
>> 'E:\msys\1.0\bin\makeinfo' is not recognized as an internal or 
>> external command,
>> operable program or batch file.
>> Project : error PRJ0019: A tool returned an error code from 
>> "Performing Post-Build Event..."
>>
>> Build log was saved at 
>> "file://e:\devel\vs71\info\info.dir\Debug\BuildLog.htm"
>> info - 1 error(s), 0 warning(s)
>>
>>
>>
>> Cheers,
>> Brandon Van Every
>>
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>



More information about the CMake mailing list