Brad King wrote:
> On 09/22/2015 09:58 AM, Robert Goulet wrote:
>> Patch attached for adding makefile to install generators.
>> This refactoring is required for install(FILES) genex support,
>> and most likely other install() signatures in the future.
>
> Thanks. I applied that and merged to
On 09/22/2015 09:58 AM, Robert Goulet wrote:
> Patch attached for adding makefile to install generators.
> This refactoring is required for install(FILES) genex support,
> and most likely other install() signatures in the future.
Thanks. I applied that and merged to 'next' for testing:
Thanks, once this is accepted in master I will send you my updated
install(FILES) with genex support. I removed the GetDestination() signature
since I agree it's not needed and might be confusing.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Tuesday,
Brad King wrote:
> On 09/16/2015 03:14 PM, Brad King wrote:
>> That eliminates my concern.
>
> This is now in 'master' as:
>
> Project: Determine default language dialect for the compiler.
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a
>
> However, I just discovered that it
On 09/22/2015 04:29 PM, Stephen Kelly wrote:
> I've pushed fix-forced-toolchain-dialect to fix this. It uses an existing
> mechanism already in use to determine whether the compiler was forced.
Looks good, thanks.
> Is there any legitimate need to force the compiler?
The CMakeForceCompiler
Hi,
A few days ago I merged a commit which moves the construction of
cmLocalGenerator objects.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3aa333d
It fails on the RunCMake.try_compile test on several dashboards in the
CMP0056 test at the end where the policy is set to NEW.
I
On 09/22/2015 04:35 PM, Robert Goulet wrote:
> Ok so that brings the question, how is 3.4 schedule looking?
The feature freeze will be Oct 1 shortly after which post-3.4 development
will open. Steve will then start his post-3.4 refactoring topic merges
and then we can come back to this feature.
On 09/22/2015 04:00 PM, Stephen Kelly wrote:
> This is going in the wrong direction.
> (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24)
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370
[snip]
> The patch from Robert should not undo that effort, so the branch
> should be
Ok then perhaps the refactoring can wait but we'd still like to get
install(FILES) destination genex support in 3.4 if possible, and genex
evaluation requires the cmMakefile. How should we proceed then?
-Original Message-
From: cmake-developers
Yeah I guess it could look something like this (attachment). However I just
realized that if I don't also get install(DIRECTORY) in 3.4 then this is not
worth rushing it, since as you mention I would also need to write proper test
cases.
Just let me know when I can start looking at this again
Brad King wrote:
> On 09/22/2015 04:00 PM, Stephen Kelly wrote:
>> This is going in the wrong direction.
>> (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24)
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370
> [snip]
>> The patch from Robert should not undo that effort,
Ok so that brings the question, how is 3.4 schedule looking?
We really wanted to get install(FILES) destination genex in CMake 3.4 release
version... this is a bit disappointing because we'll have to stick with our
custom branch another round. Oh well.
Thanks.
-Original Message-
From:
James Johnston wrote:
>> > it would be useful to have Visual Studio available as an "Extra" CMake
>> > generator. For example, specification of "Visual Studio 2015 - Ninja"
>>
>> This functionality sounds reasonable but the name of the extra/generator
>> pair looks funny when spelled out that
Robert Goulet wrote:
> Ok then perhaps the refactoring can wait but we'd still like to get
> install(FILES) destination genex support in 3.4 if possible, and genex
> evaluation requires the cmMakefile. How should we proceed then?
cmLocalGenerator has a GetMakefile method (currently). Don't you
Robert Goulet wrote:
> Yeah I guess it could look something like this (attachment).
Yes, something like that (modulo the long line).
> However I
> just realized that if I don't also get install(DIRECTORY) in 3.4 then this
> is not worth rushing it, since as you mention I would also need to
Thanks for the feedback Brad,
I have rebased the changes and I think that I have the proper default
functionality properly implemented. I've extracted the
WINDOWS_TARGET_PLATFORM_VERSION changes into a separate patch.
WINDOWS_TARGET_PLATFORM_VERSION is a target property, for that will specify
> I was looking at this issue
> http://public.kitware.com/Bug/view.php?id=13009
>
> and apparently it is not possible to install empty directories (I just
> tested).
>
> I believe that it should be possible to do that (even if there are better
> ways like postinst).
> What is your opinion?
I
Domen Vrankar wrote:
I was looking at this issue
http://public.kitware.com/Bug/view.php?id=13009
and apparently it is not possible to install empty directories (I just
tested).
I believe that it should be possible to do that (even if there are
better
ways like postinst).
What is your
> You left a commented out line in Source/CPack/cmCPackGenerator.cxx.
Hm that should not be there. I'll delete it when I get to my PC.
Thanks,
Domen
--
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
On 09/16/2015 03:14 PM, Brad King wrote:
> That eliminates my concern.
This is now in 'master' as:
Project: Determine default language dialect for the compiler.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a
However, I just discovered that it breaks use of toolchain files
that
On 09/21/2015 05:51 PM, Michael Scott wrote:
> Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and
> -Wno-err-deprecated may be trickier than expected to get behaving as
> intended. I'll try and get a better idea of the users of IssueMessage
> and see if some ideas come to mind. Removing
> This and its related changes are also refactoring that should go in its own
> commit.
Ok let's begin with this. Patch attached for adding makefile to install
generators. This refactoring is required for install(FILES) genex support, and
most likely other install() signatures in the future.
22 matches
Mail list logo
