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