[cmake-developers] User vs CMake include mismatch handling

[David Cole]

On Tue, Oct 19, 2010 at 9:46 AM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> 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
>

Thanks, Marcus. We can all use a git double-check these days... :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101019/935484e7/attachment.html>