[cmake-developers] Extracting target metadata, IDE integration

[Peter Kümmel]

On 12.03.2015 16:24, Tobias Hunger wrote:
>
> A list of *all* headers used during the building of the target would
> be fine. There is no need to filter that list down in any way.
>
> CMake has that information: Without it cmake could not possibly know
> when a cpp file needs rebuilding. It would not be as successful a
> build system when it did not know that:-)

Even cmake does not know all headers need for compilation, this is done
by the compiler providing the dependency files.

Overall, wouldn't it be better cmake could parse something like a QBS syntax?
Or is also QBS's description not complete enough for an IDE? Is it good enough
for QtCreator?

I don't think extending CMake's language until eternity is a good idea,
the way should go away from it to a common scripting language, so that
generating meta-files becomes superfluous.

>
>> Also we don't really have information about where to put them. You can
>> use the minimum common denominator among the sources I guess.
>
> I don't understand that part, sorry.
>
>>>
>>>>         }
>>>>     ],
>>>>     "installed" : "true",
>>>
>>> I guess this means "make install" will install it. Where will this file end up?
>> Yes. I tried to figure it out but didn't manage to find the correct
>> way to query it. I can try harder. :D
>>
>>>
>>>>     "name" : "LLVMPowerPCInfo",
>>>>     "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo",
>>>
>>> For what is the output directory relevant? The output above does
>>> implicitly list that already, doesn't it?
>> It's important in case the output path is overriden, see last e-mail
>> by Alexander Neundorf.
>>
>>>
>>>>     "type" : "STATIC_LIBRARY"
>>>
>>> Which types are possible here?
>> It's an enum internal to cmake. At the moment:
>> EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY,
>> OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY,
>> UNKNOWN_LIBRARY.
>>
>>>
>>>> },
>>>
>>>
>>> There is a lot of useful information here! Thanks for pushing into
>>> this direction. I am sure this will help a lot.
>>>
>>> Ideally this file would be enough to provide all information we need
>>> as an IDE to:
>>>
>>> * Present the project structure as seen by the build system.
>>> * Generate the code model
>>> * Build the project
>>> * Deploy the project
>>> * Run and debug parts of the project
>>> * Adding and removing files to a project
>>>
>>> For the project structure this does help: It provides us with a list
>>> of all the build targets, which is already nice. CMake does support
>>> more structure with Projects and subprojects IIRC and that information
>>> is lost. Would it be much work to get that information back?
>> as discussed above, I'll look into that next thing.
>
> I am a cmake noob, but maybe I can help?
>
>>> For the code model this is not much help at all: There is no
>>> information on compiler used, include directories nor Defines or
>>> compiler flags. Where am I supposed to get that information from? Do I
>>> need to generate and parse the list of commands run and extract that
>>> information from there? Having that information available right in the
>>> sources array of each target would be so much more convenient and
>>> would also make IDE integration so much easier: You would need to know
>>> about one file only and won't need to figure out several.
>> We can do that, I mentioned earlier in this thread that currently
>> we're using compile_commands.json for that (
>> CMAKE_EXPORT_COMPILE_COMMANDS).
>>
>> I agree it could be interesting to add it. In other words, if nobody
>> disagrees, I'll add it although I see how this will make the output
>> grow a lot.
>
> I found parsing of compiler commands non-trivial: It gets messy when
> some file gets built twice, especially when different defines, etc.
> are set at the different times. E.g. once it is built with
> -DENABLE_TEST by some unit test and once it is built without any flags
> by the normal application.
>
> Best Regards,
> Tobias
>