setting up cmake builddirs

[Andreas Pakulat]

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.

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

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

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

> 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

-- 
You shall be rewarded for a dastardly deed.