Re: [CMake] Auto re-configuring until cache stops changing
On Fri, Sep 10, 2010 at 10:32 AM, David Doria wrote: > On Fri, Sep 10, 2010 at 10:25 AM, David Cole > wrote: > > I think we're too close to the first release candidate of CMake 2.8.3 to > be > > adding features at this point. > > But this is a great candidate for an early change immediately after the > > 2.8.3 release. If we get it into 'next' immediately after the upcoming > > release, then all the kinks (there will be one or two, nearly guaranteed) > > should be worked out and have it ready for the 2.8.4 release a few months > > down the road. > > > > How does that sound? > > > > Thanks for the conversation, > > David C. > > Sounds great to me. Thanks for the predicted schedule. Should I put it > on the bug tracker so it is noticed when looking through features to > add? > > David > Sure, add a bug and assign it to me. Or if it doesn't let you assign it, just send me the bug number. Thanks, David C. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Fri, Sep 10, 2010 at 10:25 AM, David Cole wrote: > I think we're too close to the first release candidate of CMake 2.8.3 to be > adding features at this point. > But this is a great candidate for an early change immediately after the > 2.8.3 release. If we get it into 'next' immediately after the upcoming > release, then all the kinks (there will be one or two, nearly guaranteed) > should be worked out and have it ready for the 2.8.4 release a few months > down the road. > > How does that sound? > > Thanks for the conversation, > David C. Sounds great to me. Thanks for the predicted schedule. Should I put it on the bug tracker so it is noticed when looking through features to add? David ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
I think we're too close to the first release candidate of CMake 2.8.3 to be adding features at this point. But this is a great candidate for an early change immediately after the 2.8.3 release. If we get it into 'next' immediately after the upcoming release, then all the kinks (there will be one or two, nearly guaranteed) should be worked out and have it ready for the 2.8.4 release a few months down the road. How does that sound? Thanks for the conversation, David C. On Fri, Sep 10, 2010 at 8:08 AM, David Doria wrote: > > OK... good. I was just clarifying for the readers of the thread why we > will > > not be "auto-configuring-for-multiple-iterations"... Ever. :-) > > > > Ok, so is the voting over? There didn't seem to be much participation > (as expected...). Where does it go from here? > > David > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
> OK... good. I was just clarifying for the readers of the thread why we will > not be "auto-configuring-for-multiple-iterations"... Ever. :-) > Ok, so is the voting over? There didn't seem to be much participation (as expected...). Where does it go from here? David ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Wed, Sep 8, 2010 at 3:43 AM, Diablo 666 wrote: > Hi, > > > What I meant was that the curses and Qt UI's should behave more like > 'cmake'. > > What does cmake actually do? The following code runs into an infinite loop > on > ccmake (like intended), but cmake seems to finish after the first pass (it > just prints > out "on" once), though there is a newly introduced cache variable on every > run. > > SET (FOOBAR OFF CACHE BOOL "bla") > IF (NOT FOOBAR) > SET (FOOBAR ON CACHE BOOL "bla" FORCE) > SET (BLA ON CACHE BOOL "foobar") > UNSET (FOO CACHE) > MESSAGE (STATUS "on") > ELSE() > SET (FOOBAR OFF CACHE BOOL "bla" FORCE) > UNSET (BLA CACHE) > SET (FOO ON CACHE BOOL "barfoo") > MESSAGE (STATUS "off") > ENDIF(NOT FOOBAR) > > > Andreas > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > "cmake" configures exactly once and generates at the end of that configure, regardless of any "now new" options or settings. If you run it again, it will do the same again, and in your case, you should see the "off" message on the 2nd run. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Tue, Sep 7, 2010 at 2:11 PM, Michael Wild wrote: > > On 7. Sep, 2010, at 18:22 , David Cole wrote: > > > On Tue, Sep 7, 2010 at 11:44 AM, Michael Wild wrote: > > > >> > >> On 7. Sep, 2010, at 17:30 , David Cole wrote: > >> > >>> On Tue, Sep 7, 2010 at 11:23 AM, David Doria > >> wrote: > >>> > On Mon, Sep 6, 2010 at 9:18 AM, David Cole > >> 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. :-) ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On 7. Sep, 2010, at 18:22 , David Cole wrote: > On Tue, Sep 7, 2010 at 11:44 AM, Michael Wild wrote: > >> >> On 7. Sep, 2010, at 17:30 , David Cole wrote: >> >>> On Tue, Sep 7, 2010 at 11:23 AM, David Doria >> wrote: >>> On Mon, Sep 6, 2010 at 9:18 AM, David Cole >> 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 PGP.sig Description: This is a digitally signed message part ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Tue, Sep 7, 2010 at 11:44 AM, Michael Wild wrote: > > On 7. Sep, 2010, at 17:30 , David Cole wrote: > > > On Tue, Sep 7, 2010 at 11:23 AM, David Doria > wrote: > > > >> On Mon, Sep 6, 2010 at 9:18 AM, David Cole > 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? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
> > 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! >> > My experience supports this claim. When I was new to CMake, it struck me as odd that when using the UIs I sometimes had to explicitly configure projects multiple times, and I wondered why "Generate unconditionally" was unsupported. It took me a while to understand what was going on. Now that I understand the behavior, it does not bother me (I don't use the UIs much anyway). I think that allowing to "Generate unconditionally" would be a gain for new users, and wouldn't interfere with the usual practices of experienced users. If you want so see the new cache entries and maybe edit them, you configure; if you don't care and just want to proceed with the build, you generate. Cheers, Adolfo >> Thanks, >> >> David D. >> > > > :-) > > OK. So far, we have these votes: 32 - 0 - 0 > > Anybody else? > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Adolfo Rodríguez Tsouroukdissian, Ph. D. Robotics engineer PAL ROBOTICS S.L http://www.pal-robotics.com Tel. +34.93.414.53.47 Fax.+34.93.209.11.09 AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida. CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender at the above e-mail address. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On 7. Sep, 2010, at 17:30 , David Cole wrote: > On Tue, Sep 7, 2010 at 11:23 AM, David Doria wrote: > >> On Mon, Sep 6, 2010 at 9:18 AM, David Cole 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 PGP.sig Description: This is a digitally signed message part ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Tue, Sep 7, 2010 at 11:23 AM, David Doria wrote: > On Mon, Sep 6, 2010 at 9:18 AM, David Cole 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? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On Mon, Sep 6, 2010 at 9:18 AM, David Cole 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. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
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 On Mon, Sep 6, 2010 at 12:37 AM, Michael Wild wrote: > > On 5. Sep, 2010, at 20:30 , David Doria wrote: > > > Lately I've been making a class full of students use CMake. Without > > exception, I've had to explain why you have to configure twice to > > build VTK. I imagine they are a representative sample of the "Level 0" > > CMake user - they just want the project they are trying to build "to > > work" with default options, etc. > > > > (The explanation is here: > > http://www.cmake.org/cmake/help/runningcmake.html > > under "Why do I have to edit the cache more than once for some projects?" > > if anyone reading this is wondering) > > > > Since CMake knows if the cache has changed (it doesn't let you > > generate if it has), when why can't there be a button called "Setup > > project with default options" or "Really configure + generate" that > > configures as many times as necessary and generates all in one step? > > I bet this button would get the most clicks by the general population. > > > > Just a suggestion - any thoughts? > > > > Thanks, > > > > David > > Tell your students to run 'cmake' from the command line (the only sane way > of running CMake) and you get the desired behavior. No need to spoil your > students with GUIs and such trivia! ;-) > > But honestly, I always wondered at this strangeness, too. Why not configure > until CMake can generate? I mean, it still could remember which new cache > variables became available and highlight them for the user, but things would > be much more intuitive. > > Michael > > -- > There is always a well-known solution to every human problem -- neat, > plausible, and wrong. > H. L. Mencken > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Auto re-configuring until cache stops changing
On 5. Sep, 2010, at 20:30 , David Doria wrote: > Lately I've been making a class full of students use CMake. Without > exception, I've had to explain why you have to configure twice to > build VTK. I imagine they are a representative sample of the "Level 0" > CMake user - they just want the project they are trying to build "to > work" with default options, etc. > > (The explanation is here: > http://www.cmake.org/cmake/help/runningcmake.html > under "Why do I have to edit the cache more than once for some projects?" > if anyone reading this is wondering) > > Since CMake knows if the cache has changed (it doesn't let you > generate if it has), when why can't there be a button called "Setup > project with default options" or "Really configure + generate" that > configures as many times as necessary and generates all in one step? > I bet this button would get the most clicks by the general population. > > Just a suggestion - any thoughts? > > Thanks, > > David Tell your students to run 'cmake' from the command line (the only sane way of running CMake) and you get the desired behavior. No need to spoil your students with GUIs and such trivia! ;-) But honestly, I always wondered at this strangeness, too. Why not configure until CMake can generate? I mean, it still could remember which new cache variables became available and highlight them for the user, but things would be much more intuitive. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig Description: This is a digitally signed message part ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
