[CMake] Cmake gui and cli

James Bigler jamesbigler at gmail.com
Fri Jul 17 12:33:49 EDT 2009


This is similar to a thread a while back:

http://www.cmake.org/pipermail/cmake/2009-April/028419.html

I suggested comparing the CMakeCache.txt files before and after a configure
to get a list of relevant configuration changes and adding them to the
command line.

James

On Fri, Jul 17, 2009 at 7:54 AM, David E DeMarle
<dave.demarle at kitware.com>wrote:

> I think you can write a starter cmakecache in an empty build directory
> consisting of just the non-default options you want and and then run
> cmake on that. It will fill in the rest of what it needs if you've
> provided a consistent set that doesn't need to ask you anything.
>
> That is what dashboards do.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
>
>
>
> On Fri, Jul 17, 2009 at 4:12 AM, Alin M Elena<alinm.elena at googlemail.com>
> wrote:
> > 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.
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090717/e4ed93fa/attachment.htm>


More information about the CMake mailing list