<div class="gmail_quote">On Tue, Oct 19, 2010 at 9:46 AM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Fri, Oct 15, 2010 at 1:59 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> On Fri, Oct 15, 2010 at 1:36 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
>><br>
>> On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com">bill.hoffman@kitware.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 10/14/2010 2:18 PM, David Cole wrote:<br>
>>>><br>
>>>> On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf <<a href="mailto:neundorf@kde.org">neundorf@kde.org</a><br>
>>>> <mailto:<a href="mailto:neundorf@kde.org">neundorf@kde.org</a>>> wrote:<br>
>>>><br>
>>>> On Wednesday 13 October 2010, Alexander Neundorf wrote:<br>
>>>> > On Wednesday 13 October 2010, Bill Hoffman wrote:<br>
>>>> > > So, I think we have to use the new name approach. Do we want<br>
>>>> to call it<br>
>>>> > > 2? Or should we call it something else?<br>
>>>> > ><br>
>>>> > > Alex, do you have time to do this?<br>
>>>> ><br>
>>>> > I think it's not a good solution, and the one with<br>
>>>> CURRENT_LIST_DIR is<br>
>>>> > definitely better and already implemented.<br>
>>>> > And I am still convinced that I am right here, see my other mails.<br>
>>>><br>
>>>> So I would suggest to merge the CURRENT_LIST_DIR branch for 2.8.3,<br>
>>>> and as soon<br>
>>>> as 2.8.3 is released, remove the full paths again and enable the new<br>
>>>> CMP0017<br>
>>>> instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT) and then<br>
>>>> see what<br>
>>>> happens during the whole 2.8.4 cycle.<br>
>>>><br>
>>>> I think this (CMP0017) is necessary, because otherwise we can only<br>
>>>> hope<br>
>>>> nothing breaks with future releases (independent from FPHSA).<br>
>>>><br>
>>>> Alex<br>
>>>> _______________________________________________<br>
>>>> cmake-developers mailing list<br>
>>>> <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a> <mailto:<a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a>><br>
>>>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> I'm ok with this since Alex feels so strongly about it, and the code<br>
>>>> change is restricted to using CMAKE_CURRENT_LIST_DIR only when including<br>
>>>> FPHSA.cmake... (i.e. -- it should not affect including *other* files<br>
>>>> from inside of modules that are presently overridden... which was my<br>
>>>> concern -- that we'd break some *other* scenario -- since that's not<br>
>>>> true, I retract my objection.)<br>
>>>><br>
>>>> To review the change yourself:<br>
>>>> git fetch stage<br>
>>>> gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR<br>
>>>><br>
>>>> Look at the top 3 commits. Looks pretty safe. I'd say we should merge it<br>
>>>> to 'next' and then after a night on the dashboards, merge it to 'master'<br>
>>>> and do an rc3 release based on that.<br>
>>>><br>
>>><br>
>>> OK, lets try this one. Lets move it to next.<br>
>>><br>
>>> -Bill<br>
>>> _______________________________________________<br>
>>> cmake-developers mailing list<br>
>>> <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
>>> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br>
>><br>
>><br>
>> I'm trying to merge this, and getting conflicts when merging to 'next'<br>
>> because of changes in cmMakefile.cxx like this:<br>
>><br>
>> this->AddDefinition("CMAKE_CURRENT_LIST_FILE", filenametoread);<br>
>><br>
>> <<<<<<< HEAD<br>
>><br>
>> this->MarkVariableAsUsed("CMAKE_CURRENT_LIST_FILE");<br>
>><br>
>> =======<br>
>><br>
>> this->AddDefinition("CMAKE_CURRENT_LIST_DIR",<br>
>><br>
>><br>
>> cmSystemTools::GetFilenamePath(filenametoread).c_str());<br>
>><br>
>> >>>>>>> AddCMAKE_CURRENT_LIST_DIR<br>
>><br>
>> What's the best way to resolve this conflict? Should I delete the<br>
>> MarkVariableAsUsed lines because they're part of the dev/strict-mode branch<br>
>> which is *not* going into 2.8.3?<br>
>><br>
>> If I leave the MarkVariableAsUsed call in there, does if affect how the<br>
>> commit will merge to 'master'...?<br>
>><br>
>> Arg.<br>
><br>
> Never mind.<br>
> I think I resolved this "correctly for next" (including *both* features) and<br>
> pushed it just now. The conflict should not occur when merging to master, so<br>
> there should be nothing to resolve when I merge to master, and the<br>
> additional lines I added as conflict resolution should not end up in master.<br>
> (I'm going to verify that locally right now... :-)<br>
> Thanks,<br>
> David<br>
><br>
</div></div>Just to confirm that the current next fixes the issues I observed with<br>
CMake failing to configure Avogadro. I think your merge should be fine<br>
for master for the reason you state.<br>
<font color="#888888"><br>
Marcus<br>
</font></blockquote></div><br><div>Thanks, Marcus. We can all use a git double-check these days... :-)</div><div><br></div>