[CMake] Auto re-configuring until cache stops changing

[Michael Wild]

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

-------------- 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/aae4e61f/attachment-0001.pgp>