[cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support

[Geoffrey Viola]

Sorry for the delay. I have the experimental tests compiling again. Now, that I had a chance to dig into it, I have some questions.

> so I think this is the right place for such code.  However, the hunk above needs some work.  First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE_<LANG>_COMPILER_ID should be set to that in the code above.

Actually, I deleted that line and noticed that the tests still passed. Should I still set CMAKE_GHS_COMPILER_ID?

>The compiler path values are set to literal "${...}"
>strings but that will not be interpreted.  Alternatives:
>
>* Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm
>  and cxarm in the above code and let the normal compiler
>  search logic in CMakeDetermine*Compiler.cmake actually
>  find the compiler instead of using find_program in
>  CMakeGreenHillsFindMake.
>
>* Have EnableLanguage compute the exact path to the compiler
>  tools itself, possibly using GHS_COMP_ROOT.

I prefer the latter approach, because it will work without the user setting their PATH.

>Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake".  The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR.
>It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?).  Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT.  Then I think everything else can go in
>
> Modules/Platform/GHS-MULTI-Initialize.cmake
> Modules/Platform/GHS-MULTI.cmake

This sounds good. Unfortunately, finding the comp root is a bit complicated. The registry keys change per version and their does not seem to be a pattern. Also, the file names change per version, but start with a standard sequence. My previous method involved searching all the folders in a certain directory and doing a regex search on them. The list of matches is ordered in reverse to get the latest version. Some known registry keys are also read in case the directory is set to something not default. I'm in the process of converting the previous script code which was half of CMakeGreenHillsFindMake, to C++:

function(SUBDIRLIST curdir result)
    file(GLOB children RELATIVE ${curdir} ${curdir}/*)
    set(dirlist "")
    foreach(child ${children})
        if(IS_DIRECTORY ${curdir}/${child})
            list(APPEND dirlist ${child})
        endif()
    endforeach()
    set(${result} ${dirlist} PARENT_SCOPE)
endfunction()

set(GHS_DEFAULT_ROOT "C:/ghs")
SUBDIRLIST(${GHS_DEFAULT_ROOT} GHS_POT_DIRS)
string(REGEX MATCHALL "comp_[^;]+" GHS_REL_DIRS "${GHS_POT_DIRS}")
#Order the list so that the most recent version is searched first
list(SORT GHS_REL_DIRS)
list(REVERSE GHS_REL_DIRS)
#Make the paths absolute
set(GHS_ABS_DIRS)
foreach(GHS_REL_DIR ${GHS_REL_DIRS})
    string(CONCAT GHS_ABS_DIR ${GHS_DEFAULT_ROOT} "/" ${GHS_REL_DIR})
    list(APPEND GHS_ABS_DIRS ${GHS_ABS_DIR})
endforeach()

#Find gbuild to ensure a working path to a GHS installation
set(GHS_MAKE_PROGRAM_NAME "gbuild.exe")
find_program(CMAKE_MAKE_PROGRAM ${GHS_MAKE_PROGRAM_NAME} PATHS
    ${GHS_COMP_ROOT}
    "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\GreenHillsSoftwared771f1b4;InstallLocation]" #201414
    "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\GreenHillsSoftware9881cef6;InstallLocation]" #201254
    ${GHS_ABS_DIRS}
)
string(REGEX REPLACE "/${GHS_MAKE_PROGRAM_NAME}" "" GHS_COMP_ROOT_T ${CMAKE_MAKE_PROGRAM})
set(GHS_COMP_ROOT ${GHS_COMP_ROOT_T} CACHE PATH "Root of Green Hills Integrity executables")

> The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such.  This is likely the place for all those GHS_* cache options.

Seems like a straight forward move. I'll let you know how things work out, after I implement the above.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Monday, March 02, 2015 7:48 AM
To: Geoffrey Viola
Cc: cmake-developers at cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support

On 02/27/2015 11:29 AM, Geoffrey Viola wrote:
>> set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows")
>> We should test with at least the basic Windows PATH set.
> I made the change just now. I'll rerun the tests.

I haven't seen "glv.asi" submit in a few days.  Is it running nightly?

> Let me know if there is anything more I can do.

I've looked more through the patch sent here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12469

> +void
> +cmGlobalGhsMultiGenerator::EnableLanguage(std::vector<std::string> const &l,
> +                                          cmMakefile *mf, bool
> +optional) {
> +  mf->AddDefinition("CMAKE_C_COMPILER", "${CMAKE_GENERATOR_CC}");
> +  mf->AddDefinition("CMAKE_C_COMPILER_ID_RUN", "TRUE");
> +  mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC");
> +  mf->AddDefinition("CMAKE_C_COMPILER_FORCED", "TRUE");
> +
> +  mf->AddDefinition("CMAKE_CXX_COMPILER", "${CMAKE_GENERATOR_CXX}");
> + mf->AddDefinition("CMAKE_CXX_COMPILER_ID_RUN", "TRUE");
> + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX");
> + mf->AddDefinition("CMAKE_CXX_COMPILER_FORCED", "TRUE");
> +
> +  mf->AddDefinition("GHSMULTI", "1"); // identifier for user CMake
> +files
> +  this->cmGlobalGenerator::EnableLanguage(l, mf, optional); }

This looks based on my suggestion from an earlier review:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=11538

so I think this is the right place for such code.  However, the hunk above needs some work.  First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE_<LANG>_COMPILER_ID should be set to that in the code above.

The compiler path values are set to literal "${...}"
strings but that will not be interpreted.  Alternatives:

* Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm
  and cxarm in the above code and let the normal compiler
  search logic in CMakeDetermine*Compiler.cmake actually
  find the compiler instead of using find_program in
  CMakeGreenHillsFindMake.

* Have EnableLanguage compute the exact path to the compiler
  tools itself, possibly using GHS_COMP_ROOT.

Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake".  The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR.
It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?).  Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT.  Then I think everything else can go in

 Modules/Platform/GHS-MULTI-Initialize.cmake
 Modules/Platform/GHS-MULTI.cmake

The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such.  This is likely the place for all those GHS_* cache options.

Thanks,
-Brad

This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.