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 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 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-develop...@cmake.org <mailto: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. >>>> >>> >>> OK, lets try this one. Lets move it to next. >>> >>> -Bill >>> _______________________________________________ >>> cmake-developers mailing list >>> cmake-developers@cmake.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers >> >> >> I'm trying to merge this, and getting conflicts when merging to 'next' >> because of changes in cmMakefile.cxx like this: >> >> this->AddDefinition("CMAKE_CURRENT_LIST_FILE", filenametoread); >> >> <<<<<<< HEAD >> >> this->MarkVariableAsUsed("CMAKE_CURRENT_LIST_FILE"); >> >> ======= >> >> this->AddDefinition("CMAKE_CURRENT_LIST_DIR", >> >> >> cmSystemTools::GetFilenamePath(filenametoread).c_str()); >> >> >>>>>>> AddCMAKE_CURRENT_LIST_DIR >> >> What's the best way to resolve this conflict? Should I delete the >> MarkVariableAsUsed lines because they're part of the dev/strict-mode branch >> which is *not* going into 2.8.3? >> >> If I leave the MarkVariableAsUsed call in there, does if affect how the >> commit will merge to 'master'...? >> >> Arg. > > Never mind. > I think I resolved this "correctly for next" (including *both* features) and > pushed it just now. The conflict should not occur when merging to master, so > there should be nothing to resolve when I merge to master, and the > additional lines I added as conflict resolution should not end up in master. > (I'm going to verify that locally right now... :-) > Thanks, > David > Just to confirm that the current next fixes the issues I observed with CMake failing to configure Avogadro. I think your merge should be fine for master for the reason you state.
Marcus _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers