[cmake-developers] Generating information for C++ tools in cmake (patch)

[Manuel Klimek]

On Thu, Jan 13, 2011 at 11:43 AM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Wednesday 12 January 2011, Manuel Klimek wrote:
> ...
>> Yes, I agree that it is very conceivable that we'll want that in the
>> future - one reason I propose a JSON format is that it is both easy to
>> parse and easy to extend.
>
> Any special reason why you choose json and not xml ?
> xml is still a bit more widespread.

Yes. Parsing speed matters. Tools that run will need to parse a
potentially pretty big file. I don't have any numbers, so it's all
based on experience I have from 5 years ago where parsing XML was
painfully slow. If somebody has numbers, I'm happy to reconsider the
format ...

> I have two things in mind (not short term, but mid or long term):
>
> * have cmake write some project or buildfile which can be used as a build-tool
> independent buildfile ... well, i.e. it should contain all information to
> build the project (as makefiles do), be easily parseble (e.g. xml or json...)
> and provide enough information for IDEs, so that e.g. QtCreator could use
> this as primary project file. It should be possible that it includes not only
> the commands to compile the files, but also to link, to install, to
> preprocess only, etc. This would probably be the file you are writing now,
> but heavily extended later on.

While I see how this might be useful, it is orthogonal to the matter
I'm trying to solve, and I would vote for putting it into 2 different
files (again because I want the parsing to be fast).
The problem I'm currently solving is "how to understand the C/C++ code
in the project". What you propose would include all the dependencies,
which are a pretty huge extra chunk of information.

> * have cmake install some FooConfig.xml or FooConfig.json file (instead or
> additionally to FooConfig.cmake), which contains information about an
> installed package (like pkg-config), and which can be easily parsed by other
> tools (e.g. xml or json). This is only related to what you are doing now in
> that I think it should use the same markup language as that will use one day.

Agreed.

> I would have opted for xml, but simply because I consider it the default
> choice. I don't have a real opinion on json.

As I said, if you can make a good case for parsing XML files at the
same speed we can parse JSON, I'm happy to reconsider.
One thing we could probably do is define a subset of XML for this file
and use that, which would bring parsing speed up to par, but of course
would get rid of many of the reasons you would want XML in the first
place.

Cheers,
/Manuel