setting up cmake builddirs
mattr at kde.org
Mon Nov 12 23:09:19 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Nov 12, 2007, at 3:38 AM, Andreas Pakulat wrote:
> On 11.11.07 22:56:33, Matt Rogers wrote:
>> 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
>>> - cmake binary
>> Why do you need to change this?
> Because you're using different cmake's for different builddirs, for
> whatever reason (for example testing cmake cvs on your project, or
> trying to reproduce a bug or....)
>>> - builddir
>> This feature will need to check to make sure that the build dir isn't
>> already configured
> Hmm, why? A re-run of cmake usually doesn't break anything in your
Because cmake will barf on us if we try to rerun it with an already
configured build dir but with different parameters, IIRC. I could be
>>> 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.
> Hmm, so the logic you want is something like:
> if exists CMakeCache.txt do cd <builddir>; cmake .
> else do cd <builddir>; cmake -DINSTALL_PREFIX -DBUILD_TYPE <sourcedir>
> right? (where the cd isn't really done, instead the working dir of the
> KProcess is set properly)
basically, although using the already existing CMakeCache.txt parser
(i think it exists) would be better. :)
> Would be fine with me.
>>> 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?
> I didn't say anything is broken, that was just my weird way of asking
> wether the code that displays the files content also works without the
> file being there...
that's a funny way of asking. :)
>>> 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.
> Read carefully, it does use cmake from path currently, but the config
> dialog tries to produce an absolute path for cmake so the user
> sees which cmake he uses. The guessing done here is simply running
> "which cmake" and taking the output from that.
Well, we shouldn't be doing that either, since that's not portable at
>> 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.
> I completely agree. I was just stating that "which cmake" is not
> portable, IIRC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
More information about the KDevelop-devel