setting up cmake builddirs

[Andreas Pakulat]

On 12.11.07 17:09:19, Matt Rogers wrote:
> 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:
> >>>   - 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.

You are wrong :) In fact cmake will happily accept _at least_ BUILD_TYPE
and INSTALL_PREFIX being different from what is in the cache and change
the cache values accordingly. Just tested this.

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

Well, there's a regex-parser used in the model that displays in the
config dialog. I guess this is one of the places where many regexes are
coming from. This would probably be a bit faster with a hand-written
parser as its a really simple syntax...

Anyway, I guess that would mean having either a shared lib for manager
and builder (I assume the manager needs the cache-parser as well, if it
doesn't we can just move the config-stuff to the builder) or providing
an interface class for the cmake manager and let the builder plugin
depend on it (would create a circular dependecy between both plugins,
obviously - though that shouldn't be a problem I think)

Andreas

-- 
Don't go surfing in South Dakota for a while.