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:[email protected]]
Sent: Monday, March 02, 2015 7:48 AM
To: Geoffrey Viola
Cc: [email protected]
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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
