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