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 <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-developers@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 > Thanks, Marcus. We can all use a git double-check these days... :-)
_______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers