setting up cmake builddirs

[Andreas Pakulat]

On 12.11.07 20:58:45, Aleix wrote:
> On Nov 12, 2007 1:32 AM, Andreas Pakulat <apaku at gmx.de> 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.
> 
> I don't really see the problem with the current solution to the problem.
> I understand that your proposal is to move the builddir generation to the
> configure state. Isn't it?

Right.

> > 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
> >
> > 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
> 
> I understand that for you, configure  means running cmake to create the
> builddir. I wonder why is it necessary to have both steps splitted. Who
> wants a not configured build dir?

Probably few if any, the reason is putting the functionality into 1
place, instead of many. And configure is the proper place, for a few
reasons (IMHO of course):

- it doesn't block the user, the configure-cmake-run runs in the
  background and the user can go on working on his code, open another
  project or whatnot. While the run-stuff in the config dialog makes
  this impossible (or is it non-modal, didn't check actually)
- configure can be used when "pruning" the builddir (i.e. rm -rf *), it
  would be quite a pain to have to go to project configuration just to
  re-run cmake fully
- configure will be available anyway, if just to re-run cmake which
  sometimes is necessary (think you noticed you miss an optional
  dependecy for your project and now you installed it)

> > 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).
> 
> 'which' is not cross platform, but the function findFile I have (used in the
> project visitor) would fit our needs.

Was just a remark I wanted to get out when I saw the code ;)

> BTW, making the cmake support multiplatform (I am thinking about Windows and
> MacOS X) would mean some new features that we don't have available for now.
> For example, register features (Windows),

Huh? I think I don't understand. What has cmake support to do with the
registry (I'm assuming that was a typo, or was it not?)

> usage of ; to separe paths in $PATH (Windows),

Uhm, do you read PATH somewhere?

> or Frameworks (Macos).

I'm not that familiar with MacOSX frameworks, but this would only affect
the gui right? (and of course the generation of cmake commands, which
would then use something different from add_library/add_executable, or
some flag to those)

> Also, I am thinking that in the project configuration, instead of choosing
> what modules directory to use, we should ask the binary to use and
> extrapolate from there

I'm not sure this works reliably, especially on Linux (I think MacOs,
but definetly Windows are less problematic here), where distro's like to
put data files into various different places that you can't easily
guess. And cmake doesn't provide a way to find that out - AFAIK. We
should probably start a discussion about this on the cmake list...

Andreas

-- 
You will be the last person to buy a Chrysler.