setting up cmake builddirs

Andreas Pakulat apaku at
Mon Nov 12 21:01:15 UTC 2007

On 12.11.07 21:47:21, Alexander Neundorf wrote:
> 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.

Interesting, that adds quite some complexity I guess.

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

Hmm, I wonder wether code-completion for frameworks is easily possible
at all. After all if the headers are inside the framework there's no
existing easy way to access them, unless you write platform-specific
code.. Wow, this is going to be quite a bit more complex than I
> > 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
> message(STATUS "${CMAKE_ROOT}")

Aah, so thats a compiled-in value? Though a commandline-switch to cmake
to retrieve that would be much easier to use than writing a
CMakeLists.txt to a temp dir and reading its output, especially as even
the smalles cmake project produces more than just that status line...


Don't worry.  Life's too long.
		-- Vincent Sardi, Jr.

More information about the KDevelop-devel mailing list