setting up cmake builddirs

Matt Rogers mattr at
Mon Nov 12 23:09:19 UTC 2007

Hash: SHA1

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

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.
> Agreed.
>>> 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?
>>> 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).
>> 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  
> directly
> 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.
> Andreas

- --

Version: GnuPG v1.4.7 (Darwin)


More information about the KDevelop-devel mailing list