setting up cmake builddirs
neundorf at kde.org
Mon Nov 12 20:47:21 UTC 2007
On Monday 12 November 2007, Andreas Pakulat wrote:
> On 12.11.07 20:58:45, Aleix wrote:
> > 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?)
You can read registry values in cmake under windows and use them e.g. as paths
used in the find_xxx() commands. find_package() also checks the registry.
> > usage of ; to separe paths in $PATH (Windows),
> Uhm, do you read PATH somewhere?
Yes, e.g. find_program() uses it, and there are more env. vars supported by
cmake, and these env. vars have the platform specific separators.
> > 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
It affects the result of find_library(), maybe also of find_path/find_file
(for headers, I'd need to check). Since the result from find_library()
probably affects the include directories, it affects e.g. code completion.
Actually since any result can be used in arbitrary ways, every result can
... do something else
> 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,
Yes, it works, that's how cmake itself finds its module directory.
> 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
More information about the KDevelop-devel