Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
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 have a list of configs in CMAKE_CONFIGURATION_TYPES. You have correctly selected CMAKE_BUILD_TYPE for the new generator. Thanks, -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 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
Re: [cmake-developers] CTest update broken with non-ASCII filenames
On 09.04.2015 20:39, Rolf Eike Beer wrote: Am Donnerstag, 9. April 2015, 10:30:35 schrieb Brad King: On 04/09/2015 10:28 AM, Nils Gladitz wrote: What was the original problem you were trying to fix? You pointed out test failures on "nibble.ngladitz" which I then tried to fix: https://open.cdash.org/testDetails.php?test=316350872&build=3711574 Right, I forgot about that, thanks. So, this was exposed by using the zh_HK locale. Just guessing: C will be "ASCII", i.e. "every 8 bit character gets mangled" (or at least everything not being able to be displayed in a 256 byte codepage). So a fix could be to use something like en_US.UTF-8, if that is available on the system, which sadly may not always be the case. I merged "c-locale-messages" which tries to preserve LC_CTYPE (which affects filename encodings) in the presence of LC_ALL and sets LC_MESSAGES to C (which affects output messages). This does seem to fix both cases for me. Forcing UTF-8 might not be the correct way to go since people might be using other encoding beyond ASCII and UTF-8. It has been a while but I think I used to run linux distros with e.g. something similar to "en_US.ISO-8859-1". Haven't seen anything like that since but I am not really that familiar with what other system use ... also aren't locale names themselves platform specific? I implemented this outside of CTest hoping this might be something that could be reused elsewhere as well. Since running external processes with english ASCII messages is a common pattern I was thinking it could be added to e.g. execute_process() with a new e.g. "C_LOCALE_MESSAGES" flag? Nils -- 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
Re: [cmake-developers] CTest update broken with non-ASCII filenames
Am Donnerstag, 9. April 2015, 10:30:35 schrieb Brad King: > On 04/09/2015 10:28 AM, Nils Gladitz wrote: > >> What was the original problem you were trying to fix? > > > > You pointed out test failures on "nibble.ngladitz" which I then tried to > > fix: > > > > https://open.cdash.org/testDetails.php?test=316350872&build=3711574 > > Right, I forgot about that, thanks. So, this was exposed by > using the zh_HK locale. Just guessing: C will be "ASCII", i.e. "every 8 bit character gets mangled" (or at least everything not being able to be displayed in a 256 byte codepage). So a fix could be to use something like en_US.UTF-8, if that is available on the system, which sadly may not always be the case. Eike signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
> Please base further work on commit a00be665. Will do. >I see you added use of CMAKE_BUILD_TYPE to pick which flags to use. Does this >IDE support only one configuration at a time? >Or, are users supposed to be able to pick the config at build time? The IDE supports only one configuration at a time. As far as I can tell, typical MULTI projects are monolithic embedded compiled code where flags are edited at a global level. I figured CMAKE_BUILD_TYPE kind of works similarly except it is a little more stream lined. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -Original Message- 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 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 'next' for testing again: cmLocalGenerator: Constify some cmTarget and cmGeneratorTarget arguments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=051d8be1 Add a 'Green Hills MULTI' generator on Windows http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a00be665 Please base further work on commit a00be665. I see you added use of CMAKE_BUILD_TYPE to pick which flags to use. Does this IDE support only one configuration at a time? Or, are users supposed to be able to pick the config at build time? 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
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
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 'next' for testing again: cmLocalGenerator: Constify some cmTarget and cmGeneratorTarget arguments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=051d8be1 Add a 'Green Hills MULTI' generator on Windows http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a00be665 Please base further work on commit a00be665. I see you added use of CMAKE_BUILD_TYPE to pick which flags to use. Does this IDE support only one configuration at a time? Or, are users supposed to be able to pick the config at build time? Thanks, -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 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
Re: [cmake-developers] CTest update broken with non-ASCII filenames
On 04/09/2015 10:28 AM, Nils Gladitz wrote: >> What was the original problem you were trying to fix? > > You pointed out test failures on "nibble.ngladitz" which I then tried to > fix: > > https://open.cdash.org/testDetails.php?test=316350872&build=3711574 Right, I forgot about that, thanks. So, this was exposed by using the zh_HK locale. Thanks, -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 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
Re: [cmake-developers] CTest update broken with non-ASCII filenames
On 04/09/2015 04:15 PM, Brad King wrote: On 04/09/2015 07:54 AM, Nils Gladitz wrote: With c771f9d945444f6cfe41195e26653f368aff7f42 "CTest: To enforce the C locale use LC_ALL instead of LC_MESSAGES." I think you meant commit 6a661f06: CTest: To enforce the C locale use LC_ALL instead of LC_MESSAGES. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a661f06 Yes, sorry ... not sure how that happened. I broke svn updates for repositories which contain non-ASCII filenames. This is apparently due to me not only changing how messages are encoded but also how svn interprets filename encodings. I'll try to find a more appropriate fix. Thanks. If you are not able to find a good approach soon please revert the original change. Will do. What was the original problem you were trying to fix? You pointed out test failures on "nibble.ngladitz" which I then tried to fix: https://open.cdash.org/testDetails.php?test=316350872&build=3711574 Nils -- 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
Re: [cmake-developers] CTest update broken with non-ASCII filenames
On 04/09/2015 07:54 AM, Nils Gladitz wrote: > With c771f9d945444f6cfe41195e26653f368aff7f42 "CTest: To enforce the C > locale use LC_ALL instead of LC_MESSAGES." I think you meant commit 6a661f06: CTest: To enforce the C locale use LC_ALL instead of LC_MESSAGES. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a661f06 > I broke svn updates for repositories which contain non-ASCII filenames. > > This is apparently due to me not only changing how messages are encoded > but also how svn interprets filename encodings. > > I'll try to find a more appropriate fix. Thanks. If you are not able to find a good approach soon please revert the original change. What was the original problem you were trying to fix? -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 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
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
> I get conflicts applying on commit ff7ecb92. Please resolve.
I rebased on ff7ecb92 to create the new attached patch. Here are the test
results: https://open.cdash.org/buildSummary.php?buildid=3763362.
>> target_compile_options(${TARGET_NAME} PUBLIC
>> ":optionsFile=\"${ABS_PATH}/rel/path/filename\"")
>
>The COMPILE_OPTIONS are supposed to be given flags exactly as you'd like the
>tools to receive them, and CMake is supposed to take care of the quoting.
>This is different than the older COMPILE_FLAGS value that is just a command
>line string.
>
>Therefore I think you should be writing:
>
> target_compile_options(${TARGET_NAME} PUBLIC
> ":optionsFile=${ABS_PATH}/rel/path/filename")
>
>which is expected to work even if there is a space in the ABS_PATH value.
That seems to be working, but I need to do more testing.
Now that the flags seem to be working correctly, I'll need to remove the hard
coded "--link_once_templates" flag.
Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Wednesday, April 08, 2015 7:22 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/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 be given flags exactly as you'd like the
tools to receive them, and CMake is supposed to take care of the quoting. This
is different than the older COMPILE_FLAGS value that is just a command line
string.
Therefore I think you should be writing:
target_compile_options(${TARGET_NAME} PUBLIC
":optionsFile=${ABS_PATH}/rel/path/filename")
which is expected to work even if there is a space in the ABS_PATH value.
-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.
0001-ghs-gen-uses-cmake-vars-for-flags.patch
Description: 0001-ghs-gen-uses-cmake-vars-for-flags.patch
--
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
[cmake-developers] CTest update broken with non-ASCII filenames
With c771f9d945444f6cfe41195e26653f368aff7f42 "CTest: To enforce the C locale use LC_ALL instead of LC_MESSAGES." I broke svn updates for repositories which contain non-ASCII filenames. This is apparently due to me not only changing how messages are encoded but also how svn interprets filename encodings. I'll try to find a more appropriate fix. Nils -- 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
