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

[Michael Wild]

On 01/13/2011 09:38 PM, Manuel Klimek wrote:
> 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

Just to throw in another alternative: YAML is a superset of JSON with
added benefits, such as:

- Extensible data types.

- Relational data (i.e. you don't have to repeat identical data, just
refer to it via a an anchor). This is possibly the biggest advantage.

- Allows for block-indentation (similar to Python) without requiring
delimiters (braces, brackets, quotes).


Michael