[CMake] Feature requests for CMake-GUI

Michael Wild themiwi at gmail.com
Thu Jan 14 08:30:46 EST 2010


On 14. Jan, 2010, at 14:18 , Michael Jackson wrote:

> 
> On Jan 14, 2010, at 5:49 AM, Adolfo Rodríguez Tsouroukdissian wrote:
> 
>> 
>> 
>> 2010/1/14 Michael Wild <themiwi at gmail.com>
>> 
>> On 14. Jan, 2010, at 11:00 , Adolfo Rodríguez Tsouroukdissian wrote:
>> 
>> > On Thu, Jan 14, 2010 at 10:47 AM, Michael Wild <themiwi at gmail.com> wrote:
>> >
>> >>
>> >> On 14. Jan, 2010, at 10:43 , Michael Wild wrote:
>> >>
>> >>> Hi all
>> >>>
>> >>> I normally never use cmake-gui, but did so for writing installation
>> >> instructions. While doing so I came across some oddities and things that
>> >> would be useful:
>> >>>
>> >>> - It seems to be impossible to see the cache-variable descriptions
>> >>>
>> >>> - Since cmake now has the --build option, it would be great if cmake-gui
>> >> had the option of running some common targets (such as all, clean and
>> >> install).
>> >>>
>> >>> Are these items on the todo-list already, or should I open
>> >> feature-request for them in the tracker?
>> >>>
>> >>> Michael
>> >>
>> >> Before I forget:
>> >>
>> >> If the generator is associated with an IDE, it would be nice being able to
>> >> fire that one up!
>> >>
>> >
>> > What's your take on inverting the problem? IDEs being able to fire up
>> > cmake-gui (via a plugin or whatever). The thing is that with many IDEs (QT
>> > creator, KDevelop4, Eclipse [one of the 2 ways of using it] ) you don't
>> > invoke an IDE-specific generator, but generate plain makefiles, so if your
>> > feature request is implemented, many IDEs would be unable to take advantage
>> > of it.
>> >
>> > Btw, KDevelop4 already implements something similar, but does not fire up
>> > cmake-gui explicitly, but a (less-flexible) custom widget.
>> >
>> > Best,
>> >
>> > Adolfo
>> 
>> I try to look at it from the perspective of a user wanting to build and install a package from source. The user downloads the source code, unpacks it, fires up cmake-gui, specifies a build directory, configures the project and hits "Generate". He then wants to start the build, but first has to navigate to the build tree, identify and open the generated project file. Especially identifying the correct project file isn't that easy for non-developers, especially in the case of Visual Studio.
>> 
>> He isn't like the developer who has the project open in an IDE all the time and wants to start cmake-gui from there. He doesn't want to hack on the code, he just wants to get the "warez" installed with a minimum of clicks and questions asked.
>> 
>> Either:
>> 
>> - cmake-gui should be able to fire up some well-known IDE's (such as Xcode or Visual Studio) where the user can hit the build button (this is probably what developers and casual hackers would use, so could be hidden in a menu)
>> 
>> - offer the "build", "install" and "clean" buttons itself (that's what the normal user is probably looking for, so it should be right next to "Generate")
>> 
>> - open a file browser in the build directory (and the source directory would be also useful... Again, this is probably stuff programmers are interested in)
>> 
>> If it were for me, I'd like to have all three of them ;-)
>> 
>> Michael
>> 
>> Why do you need a user to run cmake-gui + an IDE? do you require them to tweak cmake cache variables?, because otherwise you could automate the whole process with a fire&forget script. I think that for users that just want to get the "warez" installed, doing all the cmake+IDE thing will still be entering uncharted waters ;)
>> Also, if they are not developers (which I'm guess they're not), wouldn't it be a good idea to use CPack and your package generator of choice?
>> 
>> Adolfo
>> 
> 
> I need them to use the IDE to build the project. On _some_ platforms, creating libraries that work with all the IDE versions is basically impossible so I either need to release 5 different versions of my library, requiring me to have installed ALL the various versions of the IDE or just simply have the user compile the code with their IDE.
> 
>   It would be nice to have CMake-GUI be able to open the folder or directory where the build took place or even open the IDE file. This may only work on Windows and OS X, and for certain generators but still would be nice to have.
> 
>  While we are at it, I would also like to see CMake-GUI have an Integrated "Qt Assistant" style form of the CMake Documentation. Requiring folks to use the command line or the internet is not the best possible solution. I have scripts that can generate the necessary HTML and qt index files. I usually create one after each version of CMake is released. CMakeEd also has something like this as its form of "Built-In" Documentation.
> 
> Just my thoughts.
> Mike  Jackson
> 
> 

Exactly, and having simple "VCR-controls" to build and install (and perhaps clean) would be enough for those users. They don't want to look at the IDE or the source code, they just want to build and install. Heck, it would be enough for me in the most cases (I don't like IDE's, I'm a Vim person). As a nice feature one could add a menu-entry to run CPack to create a native installer.

I think that cmake-gui could be the central place to drive simple configuration, build, packaging and installation from. For the fancy stuff the user will have to use the native generator (i.e. everything that can't be driven through cmake and cmake --build), but that's probably OK, these users won't mind.

Michael


More information about the CMake mailing list