> I've added that to the topic: > > GHS: Fix tests by finding make program when cleaning > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=79fe11f1
Great. It looks like nightly GHS tests are present and passing. > The language/config flag cache entries and all the other places that CMake > supports adding flags are all collected together by the generators. See > > cmVisualStudio10TargetGenerator::ComputeClOptions > cmMakefileTargetGenerator::GetFlags > cmMakefileTargetGenerator::GetDefines > cmNinjaTargetGenerator::ComputeDefines > cmNinjaTargetGenerator::ComputeFlagsForObject Thanks. These have been helpful. I'm still working on it. I'll probably have a patch the beginning of next week. The only piece that diverges is the way that the Green Hills MULTI generator treats a kernel as a target. It should take an additional debug flag, when compiling in DEBUG or RELWITHDEBUGINFO modes. I'm considering adding CMAKE_<LANG>_KERNEL_FLAGS[_<CONFIG> style variables to account for this. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, March 31, 2015 11:16 AM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/31/2015 12:43 PM, Geoffrey Viola wrote: >> Instead, please look at using GetCompRoot in FindGhsBuildCommand. > > Thanks for the tip. That was an easy fix. Attached is the new patch. I've added that to the topic: GHS: Fix tests by finding make program when cleaning http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=79fe11f1 >> 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. I've added that part to the topic: GHS: Initialize CMAKE_<LANG>_FLAGS[_<CONFIG>] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff7ecb92 I left out the hard-coded flag updates to the generator because it should be replaced by using these flag variables anyway. The language/config flag cache entries and all the other places that CMake supports adding flags are all collected together by the generators. See cmVisualStudio10TargetGenerator::ComputeClOptions cmMakefileTargetGenerator::GetFlags cmMakefileTargetGenerator::GetDefines cmNinjaTargetGenerator::ComputeDefines cmNinjaTargetGenerator::ComputeFlagsForObject for some examples. This generator needs to do that too. > 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. Correct. 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
