setting up cmake builddirs

[Aleix]

On Nov 12, 2007 1:32 AM, Andreas Pakulat <apaku at gmx.de> wrote:

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

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?


>
> So I'd like to move forward and do the following:
>
> a) add an edit button to allow to change the following things for each
> builddir:
>  - cmake binary
>  - builddir
>  - install prefix
>  - buildtype
>  - arbitrary cmake arguments

Mostly agree

>
> b) store that information in nested groups for each builddir, those
> settings override anything in the CMakeCache.txt when the user runs
> configure on the project
>
> 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


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?


> d) make sure the cmakecache.txt-model doesn't break down when there's no
> CMakeCache.txt file ;)


>
> This means the workflow for creating a new cmake project (or opening one
> which doesn't have a builddir yet) would be: project-configuration, add
> a builddir with apropriate options, then run Configure from the menu and
> then you can build/install.
>
> Objections? Better ideas?


Objections? Well, I don't understand why is it useful the configure option
:P.

>
>
> 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).


'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).

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

Bye!
Aleix

>
>
> --
> Never be led astray onto the path of virtue.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20071112/822dce77/attachment.html>