[cmake-developers] User vs CMake include mismatch handling
David Cole
david.cole at kitware.com
Fri Oct 15 13:36:31 EDT 2010
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101015/47fb92b2/attachment.html>
More information about the cmake-developers
mailing list