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 neund...@kde.org:
On Thursday 14 October 2010, David Cole 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 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 already implemented.
And I am still convinced that I am right here, see my other
mails.
So I would suggest to merge the CURRENT_LIST_DIR branch for
2.8.3, and
as soon
as 2.8.3 is released, remove the full paths again and enable
the new
CMP0017
instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT)
and then
see what
happens during the whole 2.8.4 cycle.
I think this (CMP0017) is necessary, because otherwise we can
only
hope nothing breaks with future releases (independent from
FPHSA).
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
I'm ok with this since Alex feels so strongly about it, and the
code
change is restricted to using CMAKE_CURRENT_LIST_DIR only when
including
FPHSA.cmake... (i.e. -- it should not affect including *other*
files
from inside of modules that are presently overridden... which
was my
concern -- that we'd break some *other* scenario -- since that's
not
true, I retract my objection.)
To review the change yourself:
git fetch stage
gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR
Look at the top 3 commits. Looks pretty safe. I'd say we should
merge it
to 'next' and then after a night on the dashboards, merge it to
'master'
and do an rc3 release based on that.
There is now a branch
PreferCMakeModulesByCMakeModulesWithPolicy-NoTrailingWhitespaceCommit
on
stage.
This contains right now only one commit, and that's the commit
which adds
a policy which decides whether files in CMAKE_ROOT are preferred
over
CMAKE_MODULE_PATH if include()d from withing CMAKE_ROOT.
Currently (in this branch) this new policy is set to WARN, i.e.
still the
old behaviour by default.
As discussed, I think for this policy the default has to be new,
because
otherwise it doesn't have the desired effect, (with WARN the
projects
will break, but with warnings).
So, are you ok if I set this policy to NEW by default ?
I would also remove the full path for the
include(FindPackageHandleStandardArgs) in this branch again.
If there are no objections, I'll do this in the next days and
then merge
into next.
Alex
It doesn't make sense to introduce a policy that defaults to NEW.
The
reason for adding a policy is to *avoid breaking* existing
projects.
The default / OLD behavior should not break anything. It is when
switched to NEW that stuff might break.
How is it that projects will break with the OLD behavior of this
policy? If OLD breaks stuff, then it's not really OLD...
Hmm, we discussed this here at length already...
With no change in behaviour (i.e. old behaviour), if some cmake
module
inside
CMAKE_ROOT does include(SomeFile), and then uses some features of
SomeFile.cmake introduced in the same cmake version in a backward
compatible
way, this breaks if there is another user-supplied SomeFile.cmake
in
CMAKE_MODULE_PATH (maybe just a copy from the previous cmake
release),
because that old SomeFile.cmake doesn't have yet the features
present in
the current cmake version which the SomeFile.cmake-using module
expects to be
present (because it's not forward-compatible).
With this policy a module in CMAKE_ROOT can rely on the fact that it
also
gets
the module it expects, i.e. the one also from CMAKE_ROOT and not
another,
potentially old and incompatible one, from CMAKE_MODULE_PATH.
That's why this policy has to be set to NEW to avoid breakage.
The result from the discussion here was to use the full path as a
quick fix
for 2.8.3, and as soon as this is out, use the new policy and see
whether/how
much breakage there is.
Alex
We may have discussed it, but it was a while ago, and my brain can't
recall specific details about how we arrived at this point.
This policy, and all CMake policies should default to OLD. But if a
project says cmake_minimum_required 2.8.4 ... then it can use the
NEW
behavior.
The old behavior is: do not load stuff from CMAKE_MODULE_PATH in a
special manner. That should be the
