setting up cmake builddirs

[Matt Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
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  
wrong.

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

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

- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHON0fA6Vv5rghv0cRAjzbAJ9TKbrpcrezfSqHsl3NzeCQL3q72QCfdxfZ
t7+JqL0pGadj/8J/sUouugk=
=wnVt
-----END PGP SIGNATURE-----