[CMake] Auto re-configuring until cache stops changing

[David Cole]

On Tue, Sep 7, 2010 at 2:11 PM, Michael Wild <themiwi at gmail.com> wrote:

>
> On 7. Sep, 2010, at 18:22 , David Cole wrote:
>
> > On Tue, Sep 7, 2010 at 11:44 AM, Michael Wild <themiwi at gmail.com> wrote:
> >
> >>
> >> On 7. Sep, 2010, at 17:30 , David Cole wrote:
> >>
> >>> On Tue, Sep 7, 2010 at 11:23 AM, David Doria <daviddoria at gmail.com>
> >> wrote:
> >>>
> >>>> On Mon, Sep 6, 2010 at 9:18 AM, David Cole <david.cole at kitware.com>
> >> wrote:
> >>>>
> >>>>> The "Generate" button should be enabled after the first configure.
> >>>>>
> >>>>> It's not enabled because the prevailing theory of the day was that
> you
> >>>>> shouldn't allow generate unless there were *no* *new* cache entries
> >> after
> >>>>> the most recent configure... -- force users to pay attention to those
> >> new
> >>>>> red entries -- in other words, it's just history and reluctance to
> >> change
> >>>>> behavior that's "always been that way"...
> >>>>>
> >>>>> I've always thought that you should be allowed to generate whenever
> you
> >>>>> want to: I'd go so far as to say that "Generate" should be enabled as
> >> soon
> >>>>> as you open cmake-gui, and that, if there have not been *any*
> configure
> >>>>> steps, it would do the same thing as command line cmake: configure
> once
> >> and
> >>>>> generate, all in one click.
> >>>>>
> >>>>> Please reply with more feedback:
> >>>>>
> >>>>> How many of you would:
> >>>>> - keep the current behavior exactly as is, it's good
> >>>>> - enable "Generate" unconditionally
> >>>>> - something in between
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> David
> >>>>>
> >>>>
> >>>> David C.,
> >>>>
> >>>> I fear all of the votes for "enable generate unconditionally" will
> never
> >> be
> >>>> cast because the users that really want/need it are not on the CMake
> >> mailing
> >>>> list. I'd like to cast 32 votes by proxy in favor of the unconditional
> >>>> generate button!
> >>>>
> >>>> Thanks,
> >>>>
> >>>> David D.
> >>>>
> >>>
> >>>
> >>> :-)
> >>>
> >>> OK. So far, we have these votes: 32 - 0 - 0
> >>>
> >>> Anybody else?
> >>
> >>
> >> I'd say CMake should re-configure automatically until it is able to
> >> generate, then stop let the user take action (modify the cache and then
> >> re-configure, or generate). I could also live with no separate
> "generate"
> >> step, like when using "cmake" from the command line. Perhaps this would
> be
> >> the most transparent for new users, but for large projects it could be a
> >> nuisance.
> >>
> >> Not sure in which bin my vote goes :-)
> >>
> >> --
> >> There is always a well-known solution to every human problem -- neat,
> >> plausible, and wrong.
> >> H. L. Mencken
> >>
> >>
> > "Configure" is always going to make exactly one configure pass.
> >
> > Any "auto-reconfigure until there are no more new options" behavior is
> iffy
> > at best, because you *could* write code (likely accidentally...) that
> always
> > adds a new option on a configure pass... and then the user would wonder
> why
> > it's taking forever... when it literally would take forever.
> >
> > The pause in between configure steps is why we have a gui. It's essential
> to
> > make things red and let people inspect the new things that just popped up
> in
> > case they do want to change the newly introduced options. If they do,
> > they're responsible for making the changes and configuring one last time
> > again before generate.
> >
> > But...... if they're happy with the values (as most newbies are) then we
> > should let them click generate right away.
> >
> > Michael, your vote goes with David's proxy votes as far as I can tell.
> 33-0
> > in favor of enabling generate so far.
> >
> > Any other votes?
>
>
> What I meant was that the curses and Qt UI's should behave more like
> 'cmake'.
>
> Michael
>
> --
> There is always a well-known solution to every human problem -- neat,
> plausible, and wrong.
> H. L. Mencken
>
>

OK... good. I was just clarifying for the readers of the thread why we will
not be "auto-configuring-for-multiple-iterations"... Ever. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100907/32a9e09d/attachment.htm>