<br><br><div class="gmail_quote">2010/1/14 Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On 14. Jan, 2010, at 11:00 , Adolfo Rodríguez Tsouroukdissian wrote:<br>
<br>
> On Thu, Jan 14, 2010 at 10:47 AM, Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On 14. Jan, 2010, at 10:43 , Michael Wild wrote:<br>
>><br>
>>> Hi all<br>
>>><br>
>>> I normally never use cmake-gui, but did so for writing installation<br>
>> instructions. While doing so I came across some oddities and things that<br>
>> would be useful:<br>
>>><br>
>>> - It seems to be impossible to see the cache-variable descriptions<br>
>>><br>
>>> - Since cmake now has the --build option, it would be great if cmake-gui<br>
>> had the option of running some common targets (such as all, clean and<br>
>> install).<br>
>>><br>
>>> Are these items on the todo-list already, or should I open<br>
>> feature-request for them in the tracker?<br>
>>><br>
>>> Michael<br>
>><br>
>> Before I forget:<br>
>><br>
>> If the generator is associated with an IDE, it would be nice being able to<br>
>> fire that one up!<br>
>><br>
><br>
> What's your take on inverting the problem? IDEs being able to fire up<br>
> cmake-gui (via a plugin or whatever). The thing is that with many IDEs (QT<br>
> creator, KDevelop4, Eclipse [one of the 2 ways of using it] ) you don't<br>
> invoke an IDE-specific generator, but generate plain makefiles, so if your<br>
> feature request is implemented, many IDEs would be unable to take advantage<br>
> of it.<br>
><br>
> Btw, KDevelop4 already implements something similar, but does not fire up<br>
> cmake-gui explicitly, but a (less-flexible) custom widget.<br>
><br>
> Best,<br>
><br>
> Adolfo<br>
<br>
</div></div>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.<br>
<br>
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.<br>
<br>
Either:<br>
<br>
- 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)<br>
<br>
- 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")<br>
<br>
- 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)<br>
<br>
If it were for me, I'd like to have all three of them ;-)<br>
<font color="#888888"><br>
Michael</font></blockquote><div><br>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 ;)<br>
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?<br><br>Adolfo<br></div></div><br>