[CMake] RC compiler on Linux - new problem

Michael Hertling mhertling at online.de
Wed Jan 4 23:01:48 EST 2012


On 01/04/2012 02:08 PM, pellegrini wrote:
> Hi Michael
> 
> first of all best wishes for 2012 !

Thanks, the same to you!

> Let's start 2012 with a new question for CMake community ! It is related 
> with prior discussions we had about rc
> compiler on Linux. Sorry but I had many things to do in the meantime and 
> I could only come back to it recently.
> 
> As a reminder, my problem was:
>     - I must use the winteracter Fortran library resource compiler
>     - it does not accept any output flag so that the output resource 
> object is always created "in-source"
>     - on Linux, it produces a .o object file instead of a .res file 
> which mess up the rc process of CMake
> 
> I tried your last suggestion that was to create a wrapper script and use 
> it as the RC when I set the WINTERACTER_RC_COMPILER variable. My 
> CMakeLists.txt file looks now like:
> 
> ...
> IF(${WINTERACTER_RC_COMPILER})
>   CONFIGURE_FILE(winteracter_rc.sh.in winteracter_rc.sh @ONLY)
>   SET(CMAKE_RC_COMPILER winteracter_rc.sh CACHE STRING "RC compiler" FORCE)
> ENDIF()
> PROJECT(toto Fortran RC)
> ...
> 
> that I build with cmake -G"Unix Makefile" -DWINTERACTER_RC_COMPILER=ON ..\.
> 
> However, the build ends up with an infinite loop that replicates endlessly the following pattern:
> 
> -- The Fortran compiler identification is Intel
> -- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort
> -- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort  -- works
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90
> -- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90 -- yes
> -- Configuring done
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_RC_COMPILER= winteracter_rc.sh
> 
> would you have an idea of what is going wrong with my settings ?
> 
> thanks a lot
> 
> Eric

First of all, I can confirm the configuration loop you've reported on.
AFAICS, this is because the CMAKE_RC_COMPILER variable mustn't be set
to certain values in the cache as they invalidate the latter and make
CMake reconfigure the project, thus resulting in the infinite loop.
Look at the following exemplary project:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RC_LOOP RC)
MESSAGE("CMAKE_RC_COMPILER: ${CMAKE_RC_COMPILER}")

When configuring with -DCMAKE_RC_COMPILER=/bin/true, everything works
fine, but with -DCMAKE_RC_COMPILER=true, the loop occurs although the
"true" executable is in the path. This behavior seems a bit faulty to
me and doesn't occur with CMAKE_C_COMPILER, e.g., in that manner, but
perhaps, a CMake developer can provide us with some enlightenment.

As a solution/workaround, you might try a full path for the wrapper
script as I have also done in my example, or change the line

SET(CMAKE_RC_COMPILER winteracter_rc.sh CACHE STRING "..." FORCE)

to

SET(ENV{RC} ${CMAKE_BINARY_DIR}/winteracter_rc.sh)

preferably also with full path, as the evaluation of the RC environment
variable seems to be more robust than CMAKE_RC_COMPILER in this regard.

Some additional remarks:

(1) The wrapper script is meant to contain a @WINTERACTER_RC_COMPILER@
    placeholder, so the CONFIGURE_FILE() command will embed the RC's
    path, and you shouldn't use WINTERACTER_RC_COMPILER as a boolean
    variable, but for the path to the actual RC executable.
    Alternatively, you might do roughly the following:

    OPTION(WINTERACTER "Use Winteracter tools" ...)
    IF(WINTERACTER)
        FIND_PROGRAM(WINTERACTER_RC_COMPILER ...)
        IF(NOT WINTERACTER_RC_COMPILER)
            MESSAGE(FATAL_ERROR ...)
        ENDIF()
        CONFIGURE_FILE(winteracter_rc.sh.in winteracter_rc.sh @ONLY)
        SET(ENV{RC} ${CMAKE_BINARY_DIR}/winteracter_rc.sh)
    ENDIF()
    PROJECT(... RC)

(2) Have you already complaint to the Winteracter people w.r.t. their
    RC's behavior? ;-) IMO, forcing the output into the same location
    as the input is hardly acceptable, as source trees might be read-
    only.

Regards,

Michael

> Michael Hertling a écrit :
>> On 10/25/2011 10:16 AM, pellegrini wrote:
>>   
>>> Hi Michael,
>>>
>>> I tried to adapt the files you gave me to my project. It almost works. 
>>> As a reminder, there were a CMakeLists.txt with an overloaded 
>>> add_executable function that created a sym_link for the rc files and a 
>>> shell  file (rc.sh) used to suit the rc compiler call to my needs.
>>>
>>> I found one problem that I still not have solved. The shell script is 
>>> declared under the following command:
>>>
>>> set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "bash rc.sh 
>>> <CMAKE_RC_COMPILER> <SOURCE> <OBJECT>")
>>>
>>> However, this command makes that even my f90 files uses the rc compiler 
>>> which obvioulsy makes my build crash. I tried to use something like 
>>> set_property(SOURCE myrcfile.rc PROPERTY RULE_LAUNCH_COMPILE ... in 
>>> order to apply the patch only when a rc file is under process but 
>>> unfortunately this property is not a valid source properties.
>>>
>>> Would you see any way to circumvent that problem ?
>>>
>>> thanks
>>>
>>> Eric
>>>     
>>
>> The rc.sh script is designed to differentiate between an RC invocation
>> and something else; this is why it is called with the RC as the first
>> argument. If the first argument of the actual command line is equal
>> to <CMAKE_RC_COMPILER>, the command line is modified to adapt to the
>> winteracter RC; otherwise, it is executed without modification. Watch
>> out for the lines starting with "Executing ..." in the output of Make.
>> If it still does not work, could you provide a small self-contained
>> example which demonstrates the issue for further investigation?
>>
>> However, I reconsidered your concern in the meantime. Possibly, it's a
>> more appropriate approach to use a wrapper script for the winteracter
>> RC to adapt the latter to CMake's expectations. This script should:
>>
>> - accept parameters according to Modules/CMakeRCInformation.cmake,
>> - link or copy the source file to a temporary directory the
>>   winteracter RC can write its output file to thereafter,
>> - move the output file where it's expected by CMake.
>>
>> This wrapper can be enabled when WINTERACTER_RC_COMPILER is set at
>> the initial configuration of the project, so you don't need to re-
>> implement ADD_EXECUTABLE() et al. - which works only once anyway -
>> or to rely on the Makefile-specific RULE_LAUNCH_COMPILE property,
>> and the RC files still don't need to be handled specially, which
>> has been the idea of ADD_EXECUTABLE()'s reimplementation. However,
>> the downside is that you can not use CMake anymore to detect the
>> winteracter RC automatically; you must do it by yourself before
>> the PROJECT() or ENABLE_LANGUGAE() command, e.g.
>>
>> IF(WINTERACTER_RC_COMPILER)
>>   CONFIGURE_FILE(rc.sh.in rc.sh @ONLY)
>>   SET(CMAKE_RC_COMPILER ${CMAKE_BINARY_DIR}/rc.sh
>>       CACHE STRING "RC compiler" FORCE)
>> ENDIF()
>> PROJECT(... RC)
>>
>> with a template rc.sh.in for the wrapper script rc.sh, containing
>> @WINTERACTER_RC_COMPILER@ somewhere. In this way, anything should
>> work as usual if WINTERACTER_RC_COMPILER is not set at the initial
>> configuration of the project, but if it is set, the wrapper script
>> is configured and forced to be used as the RC, and the subsequent
>> PROJECT() or ENABLE_LANGUGAE() command won't search for an RC by
>> themselves.
>>
>> 'hope that helps.
>>
>> Regards,
>>
>> Michael
>>
>>   
>>> pellegrini a écrit :
>>>     
>>>> thanks a lot Michael.
>>>>
>>>> Finally, this was not such a trivial problem but I should find my way 
>>>> with the examples you gave me.
>>>>
>>>> Eric
>>>>
>>>> Michael Hertling a écrit :
>>>>       
>>>>> On 10/21/2011 06:49 PM, pellegrini wrote:
>>>>>  
>>>>>         
>>>>>> Hi all,
>>>>>>
>>>>>> after digging and googling some hours I did a first step in the 
>>>>>> right direction.
>>>>>>
>>>>>> I had to add the command:
>>>>>>
>>>>>> enable_language(rc)
>>>>>> set(cmake_rc_compiler_arg1 -cif8)
>>>>>>
>>>>>> The resource compiler I (must) use is the one provided by 
>>>>>> winteracter Fortran library.
>>>>>>
>>>>>> This led me to a serie of problems related to the use of this compiler:
>>>>>>     - it does not accept any output flag so that the output resource 
>>>>>> object is always created "in-source" in the rc file directory.
>>>>>>     - on Linux, it produces a .o object file instead of a .res file
>>>>>>
>>>>>> Looking at the CMakeRCInformation.cmake I see that by construction 
>>>>>> CMake will use the following compile command:
>>>>>> "<CMAKE_RC_COMPILER> <FLAGS> <DEFINES> /fo<OBJECT> <SOURCE>"
>>>>>> with a resource object file with a .res extension.
>>>>>>     
>>>>>>           
>>>>> You might rewrite this rule variable, e.g. in order to drop
>>>>> /fo<OBJECT>, but this wouldn't resolve your issues, AFAICS.
>>>>>
>>>>>  
>>>>>         
>>>>>> On a Linux machine, this produces a wrong build command line with 
>>>>>> the path for the output object file being "/foCMakeFiles/...". This 
>>>>>> problem was raised sometime ago in the mantis bug tracker but 
>>>>>> unfortunatley the patch proposed apply for mingw using windres but 
>>>>>> not for Linux.
>>>>>>
>>>>>> Is there a fix for this ?
>>>>>>
>>>>>> If no, is there a way to inform the linker that:
>>>>>>     - my resource object file is located "in-source"
>>>>>>     
>>>>>>           
>>>>> You might create symlinks to the resource files - or copy them - so
>>>>> that the winteracter RC generates its output files within the build
>>>>> tree; note that the source tree may be read-only. This could even be
>>>>> done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY().
>>>>>
>>>>>  
>>>>>         
>>>>>>     - the extension is not .res but .o
>>>>>>     
>>>>>>           
>>>>> You might use a RULE_LAUNCH_COMPILE property in conjunction with a
>>>>> shell script which recognizes RC command lines, moves the .o to a
>>>>> .res in the correct directory and drops the undesired /fo switch.
>>>>>
>>>>> The attached CMakeLists.txt and rc.sh files outline these approaches;
>>>>> check them out with meaningful ${CMAKE_SOURCE_DIR}/{abs,srcdir}.rc
>>>>> and ${CMAKE_BINARY_DIR}/bindir.rc. However, they are untested as I
>>>>> currently haven't any RC at hand; moreover, they're restricted to
>>>>> Makefiles and won't work on Windows.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael
>>>>>
>>>>>  
>>>>>         
>>>>>> pellegrini a écrit :
>>>>>>    
>>>>>>           
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I use CMake 2.8.5 on Linux and Windows machine to build a Fortran 
>>>>>>> project.
>>>>>>>
>>>>>>> On Windows, no problem, the build and the resulting GUI are OK. On 
>>>>>>> Linux, the build seems to
>>>>>>> be OK but the resulting GUI gives an empty screen. Discussing with 
>>>>>>> Michael a few days ago made
>>>>>>> me think that it could be related to the use of an inappropriated 
>>>>>>> motif library.
>>>>>>>
>>>>>>> However, looking in more details I see with a make VERBOSE=1 that 
>>>>>>> my rc file is not built
>>>>>>> (I do not see the line "Building RC object ..."). even if it is 
>>>>>>> declared as one of my sources files.
>>>>>>>
>>>>>>> Is there some extra commands to specify to make cmake recognize and 
>>>>>>> compile a rc file ?
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> Eric
>>>>>>>             


More information about the CMake mailing list