setting up cmake builddirs
mattr at kde.org
Mon Nov 12 04:56:33 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Nov 11, 2007, at 6:32 PM, Andreas Pakulat wrote:
> currently for a cmake project one can configure multiple cmake
> via the project configuration. The dialog for setting up a new
> 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.
> 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
> - cmake binary
Why do you need to change this?
> - builddir
This feature will need to check to make sure that the build dir isn't
> - install prefix
> - buildtype
> - arbitrary cmake arguments
> 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
No, the CMakeCache.txt needs to be the master document, so to speak.
So when we change those, we update the CMakeCache.txt file.
> 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
Yes for removing the run cmake stuff, no for telling the user that
they need to configure the project. We should just start that as part
of the build process when the user runs "build" from kdevelop.
> d) make sure the cmakecache.txt-model doesn't break down when
> there's no
> CMakeCache.txt file ;)
I haven't run it yet (hardware issues) but what's broken about it?
> This means the workflow for creating a new cmake project (or
> opening one
> which doesn't have a builddir yet) would be: project-configuration,
> a builddir with apropriate options, then run Configure from the
> menu and
> then you can build/install.
Take out the Configure step and it sounds fine.
> Objections? Better ideas?
> 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).
we shouldn't be guessing it. cmake should be in the path. We've
required this for autotools and when we actually get around to
providing good automake support, i'm not going to be doing any
guessing, but requiring the person to tell us what automake they want
if they want something different from the default.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
More information about the KDevelop-devel