[cmake-developers] Generating buildsystem metadata from CMake

[Stephen Kelly]

Tobias Hunger wrote:

> Hi Anton,
> 
> you raised some good points, all of which I agree with:-)
> 
> On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
> <Anton.Makeev at jetbrains.com> wrote:
>> * If it is useful to preprocess/compile/assemble individual files from
>>  IDEs, as made possible by the Makefiles and Ninja generators, we'll need
>>  to design that.
>> 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429
>>
>>
>> This is definitely useful, but I’m not sure what kind of information
>> needed here,
>> as I see it, since we already know the files in the project, we can tell
>> make/ninja to simply compile it.
> 
> You asked me to use "cmake --build", so ideally that would be "cmake
> --build . /full/file/path" and ideally it would work with all
> generators without magic in the IDE:-)

It is also orthogonal to the metadata of the build itself and can be 
designed separately.

I filed

 http://public.kitware.com/Bug/view.php?id=15465

if you want to engage in the design or implementation of that.


> 
> Since I assume that not all build systems will allow to build
> individual files, you might want to add a flag
> "can_build_individual_files" or similar to the metadata that a
> generator can use to flag the IDE on whether the generated build
> system can build individual files or not. Then the IDE can hide that
> option if it is not applicable.

Yes. If it's not possible for xcodebuild/VS, then such a property can be 
added. Noted in 

 http://public.kitware.com/Bug/view.php?id=15462

> I would also love to see subprojects:-) CMake allows for them, doesn't it?

I don't know what 'subprojects' means to you.

>> An additional though: here only the 'project information' aspect is
>> discussed; though, to be fully machine-frienly, cmake should be able to
>> also generate parseable output (error reports etc), provide the progress,
>> etc. So, just to mull over, probably the discussed design should consider
>> such future direction.
> 
> Yes, that would be great, but I do not see how cmake can do that: It
> delegates the actual build to external tools.

Anton is talking about output of cmake itself afaik.

> So in the end during a build we will always have to deal with whatever
> output the generated buildsystem throws at us:-/ This again somewhat
> limits the usefulness of allowing the user to pick whichever generator
> they want: Some will just loose some or all the build issues.

Only allow the user to choose a generator for whose make_program you have a 
parser for.

Thanks,

Steve.