Hey Stephen, On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly <steve...@gmail.com> wrote: > No problem, thanks! I recently discovered that Creator makes fragile guesses > about source files and targets > > https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified > > so I would really like to create a solution which makes that unnecessary.
I am no expert on this part of the codebase, but I would not be surprised if it did do some stupid things when seeing cmake. We do not support that too well. >> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly >> <steve...@gmail.com> wrote: >>>> The first is should this be run in a terminal or is this a GUI. Not >>>> sure whether cmake has that information. >>> >>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a >>> target. >>> >>> http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html >>> >>> The property is harmless on non-Windows, so KDE sets it on non-Windows >>> for gui applications IIRC, but others may not. >> >> This is a hint only. >> >> If it works correctly it is nice, otherwise the user will have to >> toggle some checkbox >> to change it to his or her liking. > > Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle > stuff the gui/console distinction doesn't really fit into the buildsystem. > Maybe such a checkbox, pre-populated with the hint, is needed anyway. Not into a build system, but into an IDE:-) There is a overlap in what an IDE needs to know and what a build system then needs to generate binaries, but it both also need some information the other does not provide. >> But why not have groups of sources? >> >> [ >> "name": "testc1" >> "sourceGroups" [ >> { >> "sources": [ "foo.cpp" ], >> "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"], >> "includes": ["/opt/bat/include", "/usr/include/qt5"] >> }, >> { >> "sources": [ "bar.cpp" ], >> "defines": ["BUILD_TEST=1", "QT_CORE_LIB"], >> "includes": ["/opt/bat/include", "/usr/include/qt5"] >> } >> ] >> ] >> >> Would be simpler to parse for us. > > Perhaps. CMake already has a source group concept (for IDEs to group > sources), and your concept of a source group here seems to be about grouping > files with common includes/defines/build properties? The two concepts may be > in conflict. Right, my sourceGroups are sets of sources that have the same settings applied to them. I was coming from the CMAKE_EXPORT_COMPILE_COMMANDS output which does have the information we need for the code model, but in a rather inconvenient form. Having the files with similar flags/defines/etc. grouped would make parsing them a lot faster. Not having to parse compiler command lines would further improve things:-) So I am all for you adding this information into some JSON file. I do not think there is a conflict between CMake source groups and what I was referring to, except maybe in my poorly chosen name. > For comparison, does any other buildsystem require header listings like > this? With qmake, I can populate HEADERS, but I don't have to (for headers > which do not require moc). I am aware that listing all headers is not necessary for the build system. It is one of those things where the needs of an IDE and those of a build system differ. Qmake asks for the headers to be listed. So does Qbs, which we want to be great for IDE integration. Both will most likely not notice if you forget some, but they won't be listed in Creator then. Best Regards, Tobias -- 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
