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

Geoffrey Viola Geoffrey.Viola at asirobots.com
Tue Mar 31 12:43:44 EDT 2015


> Instead, please look at using GetCompRoot in FindGhsBuildCommand.

Thanks for the tip. That was an easy fix. Attached is the new patch. It passed the tests: https://open.cdash.org/buildSummary.php?buildid=3751365.

I think the issue where the tests seemed to have passed was that my test script CTEST_SOURCE_DIRECTORY and CTEST_BINARY_DIRECTORY were set to an old git checkout.

>> also support for the rest of the standard CMAKE_BUILD_TYPE values
>
> For all other generators and toolchains, the place we put the config-specific flags is in the CMAKE_<LANG>_FLAGS_<CONFIG> cache entries.  These values are typically initialized in the
>
>  Modules/Compiler/<id>-<lang>.cmake
>
> modules.  In this case, I think it would be:
>
>  Modules/Compiler/GHS-C.cmake
>  Modules/Compiler/GHS-CXX.cmake
>
> modules.  See Modules/Compiler/Intel-*.cmake for an example.
> Then make sure the generator reads the flag values for the current configuration and uses them.

I added the files in the patch and noted them being read, but I haven't figured out the best way to extract the flags. In the Modules/Compiler/Intel-C.cmake file CMAKE_C_CREATE_PREPROCESSED_SOURCE and CMAKE_C_CREATE_ASSEMBLY_SOURCE are set, but I wasn't sure what they did so I deleted them.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com



-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Monday, March 30, 2015 7:56 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 03/30/2015 12:49 AM, Geoffrey Viola wrote:
> cmGlobalGhsMultiGenerator::FindMakeProgram uses the definition,
> "GHS_COMP_ROOT," to find gbuild.

Thanks.  However, I don't think that approach will work.  At the point where GenerateBuildCommand is called in the case that is failing, EnableLanguage has never been run because it is not a real configuration.  One giveaway of this problem is this hunk:

> -    this->SelectMakeProgram(makeProgram, this->GetGhsBuildCommand())
> -    );
> +    this->SelectMakeProgram(makeProgram, this->GhsBuildCommand)  );

which I presume had to be done because no "mf" is available.
However, at this point in the code nothing will have populated the GhsBuildCommand member.  That's why it needs the call.

Instead, please look at using GetCompRoot in FindGhsBuildCommand.

> also support for the rest of the standard CMAKE_BUILD_TYPE values

For all other generators and toolchains, the place we put the config-specific flags is in the CMAKE_<LANG>_FLAGS_<CONFIG> cache entries.  These values are typically initialized in the

 Modules/Compiler/<id>-<lang>.cmake

modules.  In this case, I think it would be:

 Modules/Compiler/GHS-C.cmake
 Modules/Compiler/GHS-CXX.cmake

modules.  See Modules/Compiler/Intel-*.cmake for an example.
Then make sure the generator reads the flag values for the current configuration and uses them.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch
Type: application/octet-stream
Size: 5886 bytes
Desc: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150331/6e191eab/attachment.obj>


More information about the cmake-developers mailing list