On Wednesday 15 December 2010, Brad King wrote:
On 12/15/2010 05:31 PM, Brad King wrote:
+ e CMake builtin module\n
+ includer \n
+ is including a module from the CMAKE_MODULE_PATH\n
+ moduleInCMakeModulePath \n
+ which
On 12/15/2010 04:59 PM, Brad King wrote:
On 12/15/2010 04:35 PM, Alexander Neundorf wrote:
First get all information, then look and decide what to do.
Seemed the cleanest way to me.
Searching the filesystem is not cheap. Do it lazily.
I tried to incorporate all other comments, and also
On 12/15/2010 05:31 PM, Brad King wrote:
+ e CMake builtin module\n
+ includer \n
+ is including a module from the CMAKE_MODULE_PATH\n
+ moduleInCMakeModulePath \n
+ which shadows expected builtin module\n
+
On Tuesday 23 November 2010, Alexander Neundorf wrote:
On Tuesday 23 November 2010, Brad King wrote:
On 11/23/2010 03:31 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
...
I think the path forward here is:
(1) Improve documentation of CMAKE_USER_MAKE_RULES_OVERRIDE[_C]
variables
(2) Add the Custom-* file
On 11/23/2010 03:31 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
(1) Improve documentation of CMAKE_USER_MAKE_RULES_OVERRIDE[_C] variables
(2) Add the Custom-* file
On Tuesday 23 November 2010, Brad King wrote:
On 11/23/2010 03:31 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
(1) Improve documentation of
On 11/22/2010 04:06 PM, Alexander Neundorf wrote:
On Monday 22 November 2010, Brad King wrote:
The warning should be more specific about what cause errors later
on means. It could mean both with future versions of CMake and with
this version of CMake later on during *this* configuration. The
On 17-11-2010 at 23:28, in message
aanlktin6z9rxfqprwdux-qge4b_wych_fvy9dyo7d...@mail.gmail.com, David
Cole
david.c...@kitware.com wrote:
On Wed, Nov 17, 2010 at 4:50 PM, Alexander Neundorf
neund...@kde.org wrote:
On Wednesday 17 November 2010, David Cole wrote:
2010/11/17 Alexander Neundorf
On Thursday 18 November 2010, Marcel Loose wrote:
...
Hi all,
I've been following this discussion with interest for quite a while. I
was wondering if both worlds could be united (Alex's and David's) if it
were possible to set cmake_minimum_required on the command line? That
way Alex can be
On Thursday 18 November 2010, Brad King wrote:
On 11/18/2010 04:29 AM, Marcel Loose wrote:
...
This entire issue is about projects using CMAKE_MODULE_PATH to override
standard CMake modules (accidentally or intentionally). This policy
changes the *granularity* at which that has to happen.
On 11/17/2010 04:50 PM, Alexander Neundorf wrote:
That's why this policy has to be set to NEW to avoid breakage.
As Dave said, the entire design of policies is based on defaulting to WARN,
as in do what I did before but tell people it is no longer the right way.
If that doesn't make sense in
On Fri, Oct 15, 2010 at 1:59 PM, David Cole david.c...@kitware.com wrote:
On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com wrote:
On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 10/14/2010 2:18 PM, David Cole wrote:
On Thu, Oct 14, 2010 at
On Tue, Oct 19, 2010 at 9:46 AM, Marcus D. Hanwell
marcus.hanw...@kitware.com wrote:
On Fri, Oct 15, 2010 at 1:59 PM, David Cole david.c...@kitware.com
wrote:
On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com
wrote:
On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman
On 10/14/2010 2:18 PM, David Cole wrote:
On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.org
mailto:neund...@kde.org wrote:
On Wednesday 13 October 2010, Alexander Neundorf wrote:
On Wednesday 13 October 2010, Bill Hoffman wrote:
So, I think we have to use the
On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com wrote:
On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman bill.hoff...@kitware.comwrote:
On 10/14/2010 2:18 PM, David Cole wrote:
On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.org
mailto:neund...@kde.org wrote:
On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.orgwrote:
On Wednesday 13 October 2010, Alexander Neundorf wrote:
On Wednesday 13 October 2010, Bill Hoffman wrote:
So, I think we have to use the new name approach. Do we want to call
it
2? Or should we call it
So, I think we have to use the new name approach. Do we want to call it
2? Or should we call it something else?
Alex, do you have time to do this?
I want to get the CMake release out very soon.
Thanks.
-Bill
___
cmake-developers mailing list
On Tuesday 12 October 2010, David Cole wrote:
On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com wrote:
...
releases and will get us through this CMake rc cycle safely. Future
enhancements to FPHSA2 may need yet another new module, but I think
that is in the nature of this
On Tuesday 12 October 2010, Brad King wrote:
On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Bill Hoffman wrote:
Anyway, in the short term, we are going to go with FPHSA2, Alex do you
have time to do that?
FPHSA2 would have been my last choice.
In
On Wednesday 13 October 2010, Bill Hoffman wrote:
So, I think we have to use the new name approach. Do we want to call it
2? Or should we call it something else?
Alex, do you have time to do this?
I think it's not a good solution, and the one with CURRENT_LIST_DIR is
definitely better and
On Wednesday 13 October 2010, Alexander Neundorf wrote:
...
Adding FPHSA2.cmake now in 2.8.3 is safe now, but not as soon as new
features are added to it in 2.8.4 or later versions.
Projects will have copies of it and it can break just the same way then.
Example: assume projects will take a
On Wednesday 13 October 2010, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Brad King wrote:
...
Currently projects have the option to override it with CMAKE_MODULE_PATH
to providing a module with the same API but a tweaked implementation.
With the CURRENT_LIST_DIR approach that
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote:
...
Personally, I would try a rc3 with CMP0017 set to NEW and see how it
goes. It works for kdelibs and for our project at work (which doesn't
have a lot of
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
2010/10/12 Alexander Neundorf neund...@kde.org
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.org
wrote:
...
Personally, I would try a rc3 with CMP0017 set
2010/10/12 Alexander Neundorf neund...@kde.org
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
2010/10/12 Alexander Neundorf neund...@kde.org
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf
neund...@kde.org
wrote:
Remaining are as far as I see:
-set new policy CMP0017 to NEW by default
Projects with an exotic setup may break, but that's probably better than
breaking all KDE 4.5.0/1 builds. One could also argue that these projects
relied on internal implementation details of cmake. As a pro, I think this
On Tuesday 12 October 2010, Alan W. Irwin wrote:
...
cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)
because you absolutely need CMP0017. I believe most projects
(including PLplot) will eventually need that policy as well because
there is a tendency to copy and modify CMake find modules to
On Tuesday 12 October 2010, Bill Hoffman wrote:
Remaining are as far as I see:
-set new policy CMP0017 to NEW by default
Projects with an exotic setup may break, but that's probably better than
breaking all KDE 4.5.0/1 builds. One could also argue that these projects
relied on internal
2010/10/12 Alexander Neundorf neund...@kde.org:
On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
2010/10/12 Alexander Neundorf neund...@kde.org
It has its own copy of FindPackageHandleStandardArgs.cmake, which is used
in some of the Find modules. Avogadro is a dependency of Kalzium (KDE
On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Bill Hoffman wrote:
Anyway, in the short term, we are going to go with FPHSA2, Alex do you
have time to do that?
FPHSA2 would have been my last choice.
In staging there is already the branch
On Tuesday 12 October 2010 17:27:31 David Cole wrote:
On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com wrote:
On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
On Tuesday 12 October 2010, Bill Hoffman wrote:
Anyway, in the short term, we are going to go with FPHSA2, Alex
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
On Friday 08 October 2010, David Cole wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf
neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
On Monday 11 October 2010, Marcus D. Hanwell wrote:
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
So is there no chance of fixing this in a backward compatible way? One of
Prefering module in CMAKE_ROOT when include() or find_package() is called from
CMAKE_ROOT (which does
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote:
On Monday 11 October 2010, Marcus D. Hanwell wrote:
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
So is there no chance of fixing this in a backward compatible way? One of
Prefering module in
On Friday 08 October 2010, David Cole wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
will, as
On Friday 08 October 2010, David Cole wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
will, as
On Friday 08 October 2010, you wrote:
On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote:
...
Better idea:
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
will, as
all
On Tuesday 05 October 2010, James Bigler wrote:
On Tue, Oct 5, 2010 at 2:08 PM, Alexander Neundorf neund...@kde.org wrote:
...
The current behaviour is really like running an executable with a shared
library LD_PRELOADED, and hoping that the LD_PRELOADED libs will always
be work as the
On Wednesday 29 September 2010, Alexander Neundorf wrote:
...
I have some thoughts, but it's not completely clear yet.
Somehow I think if a file is include()d from CMAKE_MODULE_PATH,
CMAKE_MODULE_PATH should be considered when it does its own include()s.
If it's not included via
Changing subject in order to re-classify the discussion.
2010/9/28 Brad King brad.k...@kitware.com:
On 09/28/2010 05:20 PM, Alexander Neundorf wrote:
On Tuesday 28 September 2010, Alexander Neundorf wrote:
Is this intended this way ?
The attached tiny patch seems to make
41 matches
Mail list logo
