Looks good to me. Why not merge it to 'next' for testing? Worst case,
you can also revert it and merge again...
D
--
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15128
==
Reported By:Orion E. Poplawski
Assigned To:
stage/use-consistent-regex-for-info-strings
The change seems minor enough but the impact if it breaks something is
substantial so I wanted to get a second set of eyes on this. I set out to
fix the non-working ABI detection for craycc and crayCC, which turned out
was because the cray compiler will
On 03.09.2014 22:12, Richard Shaw wrote:
I did a cmake based build for cross-compiling for win32 on Fedora
because the autotools was going to be WAY too much work to get working
with the rpmbuild mingw macros and took a look at the generated cmake
files.
It looks like it uses a bunch of imp
On Wed, Sep 3, 2014 at 9:11 AM, Brad King wrote:
> On 09/03/2014 09:48 AM, Richard Shaw wrote:
> > The module has several issues but a major one is that it doesn't add
> > the required linker flags when using static libraries instead of shared.
> >
> > It also doesn't check for any required C fla
On 09/03/2014 02:44 PM, Sylvain Joubert wrote:
> Please find attached a patch that updates the bash completion of ctest.
Applied, thanks:
bash-completion: Complete 'ctest' label names
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2603e128
-Brad
--
Powered by www.kitware.com
Please kee
Hi,
Please find attached a patch that updates the bash completion of ctest.
It will now be able to complete the -L,-LE options and their long versions.
Regards,
Sylvain
>From 8361c9dae1540c23b5529bfb6bb4de3670ecd88a Mon Sep 17 00:00:00 2001
From: Sylvain Joubert
Date: Wed, 3 Sep 2014 20:26:17 +
On 09/03/2014 01:21 PM, Bach, Pascal wrote:
> This is only a first draft and I would like to hear if I am on the right
> track.
Yes, it looks good so far.
> + else if (this->SystemName == "WindowsCE")
> +{
> +this->SystemIsWindowsCE = true;
> +if (!this->InitializeWindowsCE(mf))
At
Looks like I missed the Description :(
This is only a first draft and I would like to hear if I am on the right track.
The patch implements the SDK selection for Windows CE.
If CMAKE_SYSTEM_NAME="WindowsCE" the user has to specify an SDK using the
variable: CMAKE_VS_WINCE_SDK
The implementation
Set CMAKE_VS_WINCE_SDK to specify the SDK.
---
Source/cmGlobalVisualStudio10Generator.cxx | 48
Source/cmGlobalVisualStudio10Generator.h |7
Source/cmGlobalVisualStudio11Generator.cxx | 12 +++
Source/cmGlobalVisualStudio11Generator.h |2 ++
So
On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote:
> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> > > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > > concrete example? Or just "any IDE and t
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
> On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > concrete example? Or just "any IDE and this feature should work everywhere
> > CMake works...?"
>
> I'm wor
On 09/03/2014 11:36 AM, Bach, Pascal wrote:
> What I meant is that is you use the generator "Visual Studio 12 (2013) ARM"
> but set the CMAKE_VS_PLATFORM_NAME="Win64"
> It would compile for Win64 not arm (like calling "Visual Studio 12 (2013)
> Win64"), so we just override it with whatever the us
> >> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK",
> >
> > I'm not sure this is really Windows CE specific. There is already
> > an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32,
> > Win64, ARM etc. This is also the variable that gets set to the SDK
> > name. Cur
On 09/03/2014 10:52 AM, Alan W. Irwin wrote:
> On 2014-09-03 09:38-0400 Brad King wrote:
>> Please construct a proposed patch with "git format-patch" and
>> attach it in a message here.
>
> DONE. See attached 0001-Update-documentation-of-try_compile.patch
Applied with minor tweaks, thanks:
Help
On 09/03/2014 10:53 AM, Bach, Pascal wrote:
>> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK",
>
> I'm not sure this is really Windows CE specific. There is already
> an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32,
> Win64, ARM etc. This is also the variable tha
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15127
==
Reported By:René J.V. Bertin
Assigned To:
On 2014-09-03 09:38-0400 Brad King wrote:
On 09/02/2014 03:52 PM, Alan W. Irwin wrote:
just go ahead an fix this documentation bug without
going through the normal dance of putting it on the bug tracker,
Please construct a proposed patch with "git format-patch" and
attach it in a message here
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Mittwoch, 3. September 2014 15:35
> To: Bach, Pascal
> Cc: cmake-developers@cmake.org; Patrick Roland Gansterer
> Subject: Re: VS 2013 WindowsCE support
>
> On 09/03/2014 05:23 AM, Bach, Pascal wrote:
> >> elsei
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15126
==
Reported By:René J.V. Bertin
Assigned To:
On 09/03/2014 09:48 AM, Richard Shaw wrote:
> The module has several issues but a major one is that it doesn't add
> the required linker flags when using static libraries instead of shared.
>
> It also doesn't check for any required C flags but that's a lesser issue.
>
> These may only be a probl
I'm probably going to end up taking over the module since it seems to be
un-maintained but I'm hesitant to make radical changes to it.
The module has several issues but a major one is that it doesn't add the
required linker flags when using static libraries instead of shared.
It also doesn't chec
On 09/02/2014 03:52 PM, Alan W. Irwin wrote:
> just go ahead an fix this documentation bug without
> going through the normal dance of putting it on the bug tracker,
Please construct a proposed patch with "git format-patch" and
attach it in a message here.
Thanks,
-Brad
--
Powered by www.kitwa
On 09/03/2014 05:23 AM, Bach, Pascal wrote:
>> elseif(CMAKE_VS_WINCE_VERSION)
>>set(CMAKE_SYSTEM_NAME "WindowsCE")
>>set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}")
>>set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}")
>
> Do we need to preserve the current behavior?
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15125
==
Reported By:Jan Rüegg
Assigned To:
==
On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf wrote:
> On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers
> wrote:
> > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > concrete example? Or just "any IDE and this feature should work
> > everywher
On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> It makes sense. But what IDE are you referring to? Eclipse? Some other
> concrete example? Or just "any IDE and this feature should work everywhere
> CMake works...?"
>
>
I'm working on KDevelop, I know for a fact though, that other IDEs are
loo
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15124
==
Reported By:Barthelemy von Haller
Assigned To:
> On 09/02/2014 11:27 AM, Bach, Pascal wrote:
> >> we should now be able to activate cross-compiling
> >> with -DCMAKE_SYSTEM_NAME=WindowsCE or -
> >> DCMAKE_TOOLCHAIN_FILE=...
> >> while still using -G "Visual Studio 12 2013" as the generator.
> >
> > I think proposal would make things cleaner.
29 matches
Mail list logo
