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

[Geoffrey Viola]

> The failures I'm linking are on /your/ nightly build.  Remember that does
>
> set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows")
>
> so nothing is in the path.  The purpose of FindGhsBuildCommand is to use any knowledge possible to find gbuild.  The equivalent method in the VS generators uses the registry to find msbuild for example.

I think the problem was related to old cache values, since gbuild is not in the path. Both the experimental and nightly test suites limit the path the same way. The experimental test does not build cleanly. Here's a link to the tests passing: https://open.cdash.org/buildSummary.php?buildid=3749371.

> Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT?

Yeah, cmGlobalGhsMultiGenerator::FindMakeProgram uses the definition, "GHS_COMP_ROOT," to find gbuild.

There's also support for the rest of the standard CMAKE_BUILD_TYPE values. These are RELWITHDEBINFO and MINSIZEREL.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com

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: 5186 bytes
Desc: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150330/2fa851f0/attachment.obj>