<br><br><div class="gmail_quote">On Sat, Jul 11, 2009 at 3:27 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 10.07.09 16:44:04, Kishore wrote:<br>
> On Friday 10 Jul 2009 4:10:17 pm Andreas Pakulat wrote:<br>
> > On 10.07.09 15:43:36, Kishore wrote:<br>
> > > On Friday 10 Jul 2009 1:38:03 pm Vladimir Prus wrote:<br>
> > > > On Friday 10 July 2009 Kishore wrote:<br>
> > > > I am not exactly sure about dialog -- that<br>
> > > > combo appears to only select what settings you want to edit -- it does<br>
> > > > not change how the launch configuration is launched -- you pick the<br>
> > > > relevant item from the menu. However, it's a bit confusing to myself,<br>
> > > > too. Andreas, can you clarify what this combobox is supposed to mean?<br>
> > ><br>
> > > If the combobox in the dialog is meant to "create" the tab below it.<br>
> > > would it not be better to have them as tabs that always exist and just<br>
> > > discard the "Launch Mode" combobox?<br>
> ><br>
> > Well, IMHO its not so nice to have 8 tabs there just because there are 8<br>
> > possible launch modes. And eventually even more if there are more launchers<br>
> > for a given launchmode (think of integrating gdb+msvc-debug on win32 for<br>
> > Debugging native apps). Thats why the tabs are added/removed based on the<br>
> > launchmode.<br>
><br>
> Hmmm... Too many tabs is not very nice but it does seem more intuitive.<br>
<br>
</div>Yeah, but using tabs for the mode would mean having nested tabs as one<br>
lauch mode can possibly supply multiple pages. For example the valgrind<br>
modes will all supply a generic setup page for the valgrind executable<br>
and some general parameters and then invidiual pages for the specific<br>
backend.<br>
<div class="im"><br>
> I take this as "the way it<br>
> is meant to be" for launchers. i.e. you cannot have GDB and another configured<br>
> in the same launch config. I am not sure about this last bit but i see no way<br>
> to allowing the user to choose the different debug launches from the menu. Are<br>
> there going to be submenus to the Debug action?<br>
<br>
</div>Well, if it makes sense to have two different Debug-Actions on the same<br>
launch config then you could have two in a submenu. For example in the<br>
valgrind case it doesn't make much sense to have just a "Profile" action<br>
and then have to choose/switch the actually used profiler (memory,<br>
threads, function-calls etc) every time. Hence each profiles has its own<br>
launch mode. I could for example imagine that remote-gdb for embedded<br>
targets could provide its own launch-mode due to vastly differing setup,<br>
but still being a Debug-Launchmode.<br>
<div class="im"><br>
> > Not sure what you mean with that. Opening a cmake project asks you already<br>
> > for the builddir for that project. If you have multiple builddirs you can<br>
> > configure them via Project->Project Configuration...->CMake and switch the<br>
> > active one there.<br>
><br>
> At least for embedded systems, there is more configuration needed for cmake.<br>
> If you look through the official cmake-gui application, you will see that it<br>
> offers more options. When cross compiling it allows you to set the compiler<br>
> either directly or by specifying a CMAKE_TOOLCHAIN_FILE. At the very least i<br>
> think that the cmake support should provide a line edit that the user can use<br>
> to specify additional options to the cmake executable.<br>
<br>
</div>Definetly needed yes. I also pass various custom options to the<br>
commandline.<br>
<div class="im"><br>
> I tried looking through the code for this but could not find where the cmake<br>
> executable is executed.<br>
<br>
</div>Its in kdevelop/projectmanagers/cmake/cmakebuilddirchooser*, shouldn't<br>
be too hard to add a line-edit there. You just need to store the content<br>
of that into the project configuration (similar to the buildtype) and<br>
then adjust the cmakebuilder in kdevelop/projectbuilders/cmakebuilder to<br>
read the value and use it (see the configure() method of the class)<br>
</blockquote><div>I saw that coming. What would you think about changing these 2 by just 1 line?<br><br>It would be nice to be able to add variables to the cache too. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
You're ugly and your mother dresses you funny.<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>