<br><br><div class="gmail_quote">On Nov 12, 2007 1:32 AM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi, currently for a cmake project one can configure multiple cmake builddirs via the project configuration. The dialog for setting up a new builddir forces the user to let cmake run before being able to close it.

<br><br>Now I just (as in the last couple of days) added configure-support for<br>projects via the projectbuilder. This allows the CMakeBuilder to run<br>cmake with a builddir+sourcedir fetched from the<br>project/buildsystemmanager. That in turn makes the above enforcement

kind of obsolete - IMHO. </blockquote><div> I don't really see the problem with the current solution to the problem. I understand that your proposal is to move the builddir generation to the configure state. Isn't it?

<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>So I'd like to move forward and do the following:<br><br>a) add an edit button to allow to change the following things for each

<br>builddir:<br>  - cmake binary<br>  - builddir<br>  - install prefix<br>  - buildtype<br>  - arbitrary cmake arguments</blockquote><div>Mostly agree <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>b) store that information in nested groups for each builddir, those<br>settings override anything in the CMakeCache.txt when the user runs<br>configure on the project<br><br>c) remove the "run cmake" stuff from the dialog and add a note that

after creating a builddir the user needs to configure the project</blockquote><div> I understand that for you, configure  means running cmake to create the builddir. I wonder why is it necessary to have both steps splitted. Who wants a not configured build dir?

<br><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>d) make sure the cmakecache.txt-model doesn't break down when there's no

<br>CMakeCache.txt file ;) </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>This means the workflow for creating a new cmake project (or opening one

<br>which doesn't have a builddir yet) would be: project-configuration, add<br>a builddir with apropriate options, then run Configure from the menu and<br>then you can build/install.<br><br>Objections? Better ideas?</blockquote>

<div><br>Objections? Well, I don't understand why is it useful the configure option :P.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Andreas PS: The "guessing" of the cmake binary is not cross-platform, but I don't have a better idea right now (uses which cmake currently).</blockquote><div> 'which' is not cross platform, but the function findFile I have (used in the project visitor) would fit our needs.

BTW, making the cmake support multiplatform (I am thinking about Windows and MacOS X) would mean some new features that we don't have available for now. For example, register features (Windows), usage of ; to separe paths in $PATH (Windows), or Frameworks (Macos).

<br><br>Also, I am thinking that in the project configuration, instead of choosing what modules directory to use, we should ask the binary to use and extrapolate from there <br><br>Bye!<br>Aleix<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><font color="#888888"><br>--<br>Never be led astray onto the path of virtue.<br><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></font></blockquote></div><br>