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
_______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers