On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol <aleix...@kde.org> wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
> <anton.mak...@jetbrains.com> wrote:
>> Hey everyone,
>>
>> We are developing CLion at JetBrains that utilizes CMake as its main project
>> model. Stephen Kelly timely drew our attention to this discussion, and I’d 
>> like
>> to share some thoughts. Here are the general ones and I’ll also comment on
>> separate messages in the thread.
>>
>>
>> We’ve managed to get almost all the necessary project information,
>> using ‘GNU/MinGW Makefiles’ generators:
>>
>> * list of targets comes from 'CMakeFiles/TargetDirectories.txt'
>> * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’
>> * list of headers and resources from ‘codeblocks.cbp’ file
>> * per-file/target compiler and its flags from 
>> ‘CMakeFiles/Target.dir/flags.make’
>> * location of product files from ‘CMakeFiles/Target.dir/build.make’
>>
>>
>> What we miss (not all of them are directly related the targets metadata,
>> but I'd like to share anyway since the topic is about IDE integration):
>>
>> * Location of every source file and target in CMakeLists
>>   - it would greatly help to refactorings, navigation etc.
> In the implementation I'm proposing, the target is specified. The file
> is hard to figure out given that it's passed as a string argument and
> it could come virtually from anywhere (i.e. glob, operations, a set()
> somewhere else, etc.). My conclusion is that knowing the target
> position is already a good enough help.
>
>> * Complete list of headers and resource files
>>   - they are only listed in special generators like code blocks.
> I'll look into it, what do you need exactly? The headers in each target?
>
>> * An easily parseable list of errors and warnings with origin information.
>>   At the moment we parse error output but not everything can be parsed 
>> reliably.
> Agreed, It's something we're missing as well. I also don't really like
> the fact that sometimes the paths are absolute and sometimes they're
> relative, especially in the relative case, since it's hard to tell if
> it's relative to the build directory or source directory.
>
>> * No progress indication. Since the generation may take several minutes,
>>   providing feedback is crucial.
> I never found such case, I would argue that a project which has a
> cmake script that takes several minutes is broken, but maybe we can
> open a thread to discuss it?
>
>> * Ability to distinguish a library from an executable target.
>>   This will help to offer a better UI for run/debug configurations.
> It's included in the proposed implementation.
>
>> * Possibility to collect information for every build target in one run.
>>   Currently, we have to invoke generator for every CMAKE_BUILT_TYPE 
>> separately.
> Well, that's because you use CodeBlocks generators. It seems like for
> example in MSVC they generate many build configurations at once. This
> implementation supports having parallel debug/release builds. Then we
> can fix make/ninja generators or even create new ones.
>
>> * CMake stops processing when it find a missing file, so that IDE cannot have
>>   full project model, until this files is created.
> Well, it's related to the error generation issue we discussed. I think
> it's something we should discuss in parallel.
>
>> * When there are existing in-source generated files in the project dir,
>>   CMake doesn't allow generating into a separate out-of-source folder.
>>   An IDE has to invent workarounds here.
> Arguably, in-source generation is broken by definition...
>
>> * Not sure if it’s possible at all - a lightweight phase where CMake only
>>   collects necessary information (list of files/targets, compiler settings).
>>   This will help IDE react to the changes much faster.
> That would be extra-cool, agreed. Maybe it's an iteration we can
> consider in the future.
>
>>
>>
>> Here is why I think the discussed functionality should not be a separate
>> generator:
>>
>> CLion doesn’t have it’s own project model nor is intended as build tool
>> replacement. Currently, the only option for CLion users is makefiles build, 
>> that
>> is not a best option for everyone: there is a good and fast alternative 
>> ‘Ninja’.
>> Ideally, users should be able to choose whatever tool better suites them.
>>
>> The problem is that the generated Makefiles are used both, for internal 
>> needs,
>> like reading project structure, and also to build and run the user’s program.
>> If we wanted to support Ninja generator, we would need to rewrite all the 
>> logic
>> that retrieves the project information, using the files that are created by
>> Ninja generator. While I suppose it’s possible, it’s not the best option - 
>> very
>> error prone and resource demanding.
>>
>> If CMake generated a separate descriptor, regardless the generator used
>> (Makefiles, Ninja), it would be much easier to support; and the users will
>> benefit from better, more reliable and faster CMake integration in an IDE.
>
> I'd really appreciate your feedback on the patch I provided, I'll be
> happy to provide the information you miss.
>
> Aleix

By the way, I just looked into the Implementation for obtaining the
header files in the CodeBlocks generator and I don't think we want
something like that in a standarized file:
https://paste.kde.org/pbzigoaq5
It's basically based on conjectures over the actually built files, if
such thing needs to be done, it can be done by the IDE just as well.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to