[cmake-developers] User vs CMake include mismatch handling
Marcus D. Hanwell
marcus.hanwell at kitware.com
Tue Oct 19 09:46:31 EDT 2010
On Fri, Oct 15, 2010 at 1:59 PM, David Cole <david.cole at kitware.com> wrote:
> 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
>
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
More information about the cmake-developers
mailing list