[CMake] Cmake gui and cli

[Alin M Elena]

Hi Bill and Eric,

I see your points about the implementation but I think you are thinking to 
something different that I have  in my mind.

I am not interested in portability. When I try to compile a big project (eg 
paraview) the -gui is a very good tool, due to its incremental support. Then I 
go let us say to a production environment where I am command line and I want a 
one-go approach.

The programmatic set variables are of no value to me as they will be set the 
same in the command line environment. I need a track of all the variables that 
I set. The only thing that I want to keep track of are my changes, as they are 
the only one that change the flow of the compilation process.

regards,

Alin
-- 
 ______________________________________________________________________
 "If the Universities will not study useless subjects, who will?"
                             G. F. FitzGerald, Nature, 45/46, 392 (1892)
 ______________________________________________________________________
 Mr  Alin M ELENA
 Irish Centre for High-End Computing -- www.ichec.ie
 The Design Tower, Trinity Technology & Enterprise Campus
 Grand Canal Quay,  Dublin 2, Ireland
 Tel:   +353 (0) 1 5241608 ext 29
 Fax: +353 (0) 1 7645845
 http://alin.elenaworld.net
 alin.elena at ichec.ie
 alinm.elena at gmail.com
 ______________________________________________________________________
On Thursday 16 July 2009 20:21:02 you wrote:
> 2009/7/16 Bill Hoffman <bill.hoffman at kitware.com>:
> > Alin M Elena wrote:
> >>> I think the previous posts are missing the question....   I think what
> >>> is wanted is a way to run cmake-gui pick some options, and then
> >>> generate a -D command line equivalent to the options that were picked
> >>> in cmake-gui.  This is not possible, and would be difficult to
> >>> implement.
> >>
> >> Thanks Bill, exactly what I wanted to know.  Why is that difficult?
> >
> > All options in the cache are stored together, some are set from the
> > cmakelists.txt files and some are set by users.  I suppose camke-gui
> > could try and track all changes made by the user and collect them up. I
> > am not sure that the set of options would be portable to a different
> > machine.
>
> I may add some other similar possible issues.
>
> Sometimes as Bill said some options do appear on a specific machine basis
> like in
> IF (WIN32)
>      OPTION(WHATEVER "You know"  FALSE)
> ENDIF(WIN32)
>
> of
>
> FIND_PACKAGE(Doxygen)
> IF (DOXYGEN_FOUND)
>      OPTION(BUILD_DOC "Build documentation using Doxygen" OFF)
> ENDIF(DOXYGEN_FOUND)
>
> or even more, one option may trigger another one
>
> OPTION(LEVEL1 "level1" OFF)
> IF (LEVEL1)
>     OPTION(LEVEL2 "level2" OFF)
> ENDIF(LEVEL1)
>
> in this second case the GUI will show you the LEVEL2 option
> only if you set LEVEL1 to ON and hit configure.
>
> The CMake gui (QT or curse) have an iterative usage pattern
>
> 1) configure
> 2) select change
> 3) eventually go to 1
> 4) generate
>
> The pure command line is usually "one-shot" trying to get the
> "preferred" configuration.
>
> Like Bill said a possible way to do it would be to track user-modified
> values vs programmatically chosen ones. But you'll have to deal with
> user-modified values depending on programmatically chosen path,
> not that easy to do.