[cmake-developers] User vs CMake include mismatch handling

[David Cole]

On Fri, Oct 15, 2010 at 1:36 PM, David Cole <david.cole at kitware.com> wrote:

> On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman <bill.hoffman at kitware.com>wrote:
>
>> On 10/14/2010 2:18 PM, David Cole wrote:
>>
>>> On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf <neundorf at kde.org
>>> <mailto:neundorf at 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 at cmake.org <mailto:cmake-developers at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101015/d71e0f88/attachment.html>