The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13466
==
Reported By:Daniel Franke
Assigned To:
Mostly stable releases a week or so after non RC is released...
On Fri, Aug 10, 2012 at 11:39 AM, David Cole wrote:
> Have you even used a "nightly CMake" from the last month or so, or
> have you only been using release candidates and official releases?
>
>
> On Fri, Aug 10, 2012 at 2:35 PM, J De
Have you even used a "nightly CMake" from the last month or so, or
have you only been using release candidates and official releases?
On Fri, Aug 10, 2012 at 2:35 PM, J Decker wrote:
> Ya, unfortunatly I don't have the specific case that was failing
> anymore... it's probably because I've been u
Ya, unfortunatly I don't have the specific case that was failing
anymore... it's probably because I've been using the same build output
since 2.8.6 and just keep updating cmake... last couple versions have
actually gone smoothly
On Fri, Aug 10, 2012 at 4:21 AM, David Cole wrote:
> Can you try ag
Okay figured out the required mods to use the common version variable...
http://public.kitware.com/Bug/view.php?id=11866#c30208
On Fri, Aug 10, 2012 at 5:23 AM, Brad King wrote:
> On 08/09/2012 09:00 PM, J Decker wrote:
>> Please make mod to fix (last message has correction)
>>
>> http://pu
David Cole wrote:
> On Fri, Aug 10, 2012 at 10:57 AM, Brad King
> wrote:
>>> Do you also have a script to clear the contents of endforeach(),
>>> endif(), endmacro(), endfunction()? Or do you not want to do that?
>>
>> That's a bit more risky because sometimes they span multiple lines.
>> I'd rat
On 08/10/2012 10:30 AM, Stephen Kelly wrote:
> I've updated the branch with the API change to use std::set. The XCode
> generator does not use the cmLocalGenerator::AppendDefines method, but the
> VisualStudio6Generator does.
That wasn't quite what I had in mind. The string of escaped
defines
On 08/10/2012 10:52 AM, Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>> Brad King wrote:
>>
>>> Hi Folks,
>>>
>>> With 2.8.9 out we'd like to perform two sweeping style change commits:
>>>
>>> (1) Remove all remnants of trailing whitespace
>>> (2) Convert all CMake language code to use lower-case
On Fri, Aug 10, 2012 at 10:57 AM, Brad King wrote:
> On 08/10/2012 10:52 AM, Stephen Kelly wrote:
>> Stephen Kelly wrote:
>>
>>> Brad King wrote:
>>>
Hi Folks,
With 2.8.9 out we'd like to perform two sweeping style change commits:
(1) Remove all remnants of trailing whites
Stephen Kelly wrote:
> Brad King wrote:
>
>> Hi Folks,
>>
>> With 2.8.9 out we'd like to perform two sweeping style change commits:
>>
>> (1) Remove all remnants of trailing whitespace
>> (2) Convert all CMake language code to use lower-case commands
>>
Do you also have a script to clear the
Brad King wrote:
> Hi Folks,
>
> With 2.8.9 out we'd like to perform two sweeping style change commits:
>
> (1) Remove all remnants of trailing whitespace
> (2) Convert all CMake language code to use lower-case commands
>
Sounds great to me :)
Thanks,
Steve.
--
Powered by www.kitware.com
Brad King wrote:
> On 08/10/2012 08:53 AM, Stephen Kelly wrote:
>> The point of doing it in a separate test was to be more clearly able to
>> see the duplication without it getting lost in a different test, and to
>> be able to see which one sets which definition first (add_defintions or
>> set_pr
Hi Folks,
With 2.8.9 out we'd like to perform two sweeping style change commits:
(1) Remove all remnants of trailing whitespace
(2) Convert all CMake language code to use lower-case commands
These changes are likely to conflict with many changes others may
be doing. We'd like to first merge or
On 08/10/2012 08:53 AM, Stephen Kelly wrote:
> The point of doing it in a separate test was to be more clearly able to see
> the duplication without it getting lost in a different test, and to be able
> to see which one sets which definition first (add_defintions or
> set_property(COMPILE_DEFINI
Brad King wrote:
> On 08/10/2012 04:53 AM, Stephen Kelly wrote:
>> I've merged a branch into next to ensure that compiler definitions are
>> only added one time on the command line.
>
> The "Preprocessor" test already has extensive coverage of
> COMPILE_DEFINITIONS. Can that test be extended for
David Cole wrote:
> I assume it's the "qt4_use_modules" branch on the stage?
>
Yes, sorry, I should have pointed that out.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the
On 08/10/2012 04:53 AM, Stephen Kelly wrote:
> I've merged a branch into next to ensure that compiler definitions are only
> added one time on the command line.
The "Preprocessor" test already has extensive coverage of COMPILE_DEFINITIONS.
Can that test be extended for your cases instead of addin
On 08/09/2012 09:00 PM, J Decker wrote:
> Please make mod to fix (last message has correction)
>
> http://public.kitware.com/Bug/view.php?id=11866#bugnotes
>
> I don't have git available at this moment, but it's a one line change...
See the note I just added here:
http://www.cmake.org/Bug
I assume it's the "qt4_use_modules" branch on the stage?
On Fri, Aug 10, 2012 at 5:03 AM, Stephen Kelly wrote:
>
> Hi,
>
> I've added a qt4_use_modules function to Qt4Macros.cmake. I'm looking for
> some review before merging it to next.
>
> As qt5_use_modules is the best way to use Qt5, and as i
Can you try again with a nightly build of CMake?
There's a change that we did not take that *is* in the nightly build,
but is not in the 2.8.9 release. I'd like to know if that change is
responsible for this behavior.
We were uncertain of this commit [
http://cmake.org/gitweb?p=cmake.git;a=commit
Hi,
I've added a qt4_use_modules function to Qt4Macros.cmake. I'm looking for
some review before merging it to next.
As qt5_use_modules is the best way to use Qt5, and as it is easier to port
from qt4_use_modules to qt5_use_modules than to port from the free use of
cmake commands for include
Hi,
I've merged a branch into next to ensure that compiler definitions are only
added one time on the command line.
I haven't yet merged it to next because I'm not sure if other generators
need a similar change (I tested with Makefiles and Ninja), and I'm not sure
if there's any reason it is
David Cole wrote:
> On behalf of myself, Ken, Bill, Brad, Alex, Zach, Ben, Eike, Eric and
> the rest of the CMake team from all around the world, we are pleased
> to announce that CMake 2.8.9 is now available for download at:
>
> http://www.cmake.org/files/v2.8/?C=M;O=D
Congratulations on the
23 matches
Mail list logo