Currently the test you created is the *only* test for the generator.
Anything not covered in that test will not be known to work. We either need
to figure out how to run more of the CMake test suite (without adding
GHS-specific content to the other tests), or more of the tests need to be
On 04/16/2015 10:03 AM, Geoffrey Viola wrote:
I changed the tag on the library project file
Applied, thanks:
GHS: changed library project structure
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d19a3ec8
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the
On 04/15/2015 10:47 AM, Geoffrey Viola wrote:
I noticed that libraries are probably not set up properly
Currently the test you created is the *only* test for the
generator. Anything not covered in that test will not be
known to work. We either need to figure out how to run more
of the CMake
...@kitware.com]
Sent: Tuesday, April 14, 2015 11:14 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 04/14/2015 12:07 PM, Geoffrey Viola wrote:
It was easy to add some pre and post build
On 04/14/2015 12:07 PM, Geoffrey Viola wrote:
It was easy to add some pre and post build commands
Thanks, but something needs to verify that these actually
get executed. They could do other operations like use
${CMAKE_COMMAND} -E copy to put files somewhere that
can be checked.
There
Currently the Tests/GhsMulti project in the test suite is very minimal.
Please look at expanding it to cover more of the generator implementation.
It needs add_custom_target and add_custom_command, for example. They could
just run a simple ${CMAKE_COMMAND} -P mycode.cmake script to
On 04/12/2015 11:01 PM, Geoffrey Viola wrote:
Attached is the patch
Thanks. I've applied it:
GHS: removed hard coded flag and cleaned cmds
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2e650bf
and will squash it in before merging to 'master'.
I also extended the topic with slight
Please base further work on commit a00be665.
It looks like the previous changes are working well. I cleaned up some
unnecessary flag logic, removed a hard coded --link_once_templates flag, and
reinterpreted custom commands for easier user input. Attached is the patch.
Here's a link to the
On 04/09/2015 08:56 AM, Geoffrey Viola wrote:
I rebased on ff7ecb92 to create the new attached patch.
Thanks. I moved the cmLocalGenerator change out into its own
commit and then squashed everything else in the original topic
and this patch together. I made a few minor tweaks and merged
to
On 04/09/2015 12:58 PM, Geoffrey Viola wrote:
The IDE supports only one configuration at a time.
I figured CMAKE_BUILD_TYPE kind of works similarly
Good. The CMAKE_BUILD_TYPE is exactly for single-config generators
to select the config. Multi-config generators do not use that and
instead
Attempt at Green Hill MULTI IDE
Generator Support
On 04/08/2015 01:20 AM, Geoffrey Viola wrote:
Attached is a patch based off of the previous commit.
I get conflicts applying on commit ff7ecb92. Please resolve.
target_compile_options(${TARGET_NAME} PUBLIC
:optionsFile=\${ABS_PATH}/rel
-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Thursday, April 09, 2015 10:54 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 04/09/2015 08:56 AM, Geoffrey Viola wrote:
I rebased
On 04/08/2015 01:20 AM, Geoffrey Viola wrote:
Attached is a patch based off of the previous commit.
I get conflicts applying on commit ff7ecb92. Please resolve.
target_compile_options(${TARGET_NAME} PUBLIC
:optionsFile=\${ABS_PATH}/rel/path/filename\)
The COMPILE_OPTIONS are supposed to
Attached is a patch based off of the previous commit.
Some of the changes made were due to cmGhsMultiTargetGenerator's use of
this-LocalGenerator-AddCompileOptions forcing the cmTarget* member to lose
its constness. The other target generators use this method, but some of the
] 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
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
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
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
On 03/25/2015 11:39 AM, Brad King wrote:
http://cmake.org/gitweb?p=cmake.git;a=commit;h=8f547be5
We can still add more fixup commits as needed for nightly testing.
Please base further work, if any, on that commit for now.
Two GHS tests still fail:
On 03/26/2015 01:50 PM, Geoffrey Viola wrote:
Do you have Green Hills MULTI installed? If so which version is installed?
No. 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
I added some more commits to tweak a few things too:
And a few more to fix our continuous testing results:
GHS: Do not use C++11 enum name scope
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4427fa9
GHS: Use !foo.empty() instead of foo.size() 0
On 03/25/2015 11:15 AM, Geoffrey Viola wrote:
Please provide some text (prose) to summarize the new generator.
Green Hills MULTI is an IDE for embedded real-time systems.
Thanks. I've squashed the topic so far down into:
Add a 'Green Hills MULTI' generator on Windows
The #include line needs to be moved similarly. I made that fix and a few
whitespace fixes. I've attached a patch with those revisions.
Thanks.
I noticed while making those fixes that you're using auto_ptr inside a map
value. The auto_ptr is documented as not suitable for use in
On 03/24/2015 09:14 AM, Geoffrey Viola wrote:
Attached is a new patch.
Thanks. I've applied it and merged to 'next' for testing. I added
some more commits to tweak a few things too:
Add a 'Green Hills MULTI' generator
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1128a5f7
Help:
On 03/24/2015 11:54 AM, Brad King wrote:
I added some more commits to tweak a few things too:
And a few more to fix our continuous testing results:
GHS: Do not use C++11 enum name scope
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4427fa9
GHS: Use !foo.empty() instead of foo.size()
On 03/19/2015 09:57 AM, Geoffrey Viola wrote:
I moved it under
#if defined(_WIN32) !defined(__CYGWIN__)
# if !defined(CMAKE_BOOT_MINGW)
The #include line needs to be moved similarly. I made that fix and
a few whitespace fixes. I've attached a patch with those revisions.
I noticed while
On 03/19/2015 09:57 AM, Geoffrey Viola wrote:
Fixed.
Great, thanks. I'll take another look at the updated patch next week.
-Brad
--
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
, 2015 1:56 PM
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/16/2015 02:03 AM, Geoffrey Viola wrote:
Done
Thanks for the updates.
I just noticed that in some of the new C++ sources you copied
-developers@cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 03/11/2015 01:39 PM, Geoffrey Viola wrote:
Attached is a patch with the recommended changes
Thanks! The basic toolchain initialization is pretty close.
Here are more
Viola
Cc: cmake-developers@cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 03/11/2015 01:39 PM, Geoffrey Viola wrote:
Attached is a patch with the recommended changes
Thanks! The basic toolchain initialization is pretty close.
Here
-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 03/10/2015 12:57 AM, Geoffrey Viola wrote:
Should I still set CMAKE_GHS_COMPILER_ID?
I don't see any reason to set a variable by that name.
* Have EnableLanguage compute the exact path to the compiler tools
itself, possibly
On 03/11/2015 01:39 PM, Geoffrey Viola wrote:
Attached is a patch with the recommended changes
Thanks! The basic toolchain initialization is pretty close.
Here are more comments.
In Modules/Platform/GHS-MULTI-Initialize.cmake:
+#Setup consistent compiler executables
On 03/10/2015 12:57 AM, Geoffrey Viola wrote:
Should I still set CMAKE_GHS_COMPILER_ID?
I don't see any reason to set a variable by that name.
* Have EnableLanguage compute the exact path to the compiler
tools itself, possibly using GHS_COMP_ROOT.
I prefer the latter approach
[snip]
: [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
Viola
Cc: cmake-developers@cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 02/27/2015 10:56 AM, Geoffrey Viola wrote:
Is there something I can do to improve or expedite the process of
pulling my changes?
Sorry it's taking so long
On 02/27/2015 10:56 AM, Geoffrey Viola wrote:
Is there something I can do to improve or expedite the process
of pulling my changes?
Sorry it's taking so long but this is a huge change to review
and the testing infrastructure was only just worked out.
Your dashboard script still says
36 matches
Mail list logo
