[CMake] Auto re-configuring until cache stops changing

[Michael Wild]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100907/44c9cc6c/attachment.pgp>