Tobias Hunger wrote: > Sorry, I am a bit late with replying to this... I do not follow this > list too closely and got distracted by mails in between where I could > not contribute anything:-/
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. > > 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. > >>> Secondly the linker flags would be nice to know. That way the >>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the >>> libraries are found. >> >> If the linker flags were provided, you would have to parse them. Maybe a >> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to >> the content passed to the option -rpath. I have no idea if similar >> information can be acquired for MSVC/Windows. As Nils said, CMake might >> not know the location of the import library. > > If CMake knows the locations, then put them in, please. I'm sure that won't be a problem. > 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. >> Afaik, CMake does not know all the files included by your cpp files. >> However, some buildsystems can add them to the list of sources if desired >> for better IDE integration. >> >> https://gitorious.org/grantlee/grantlee/commit/3eb40cf94 > > That is the big issue I have with CMake... it makes it impossible to use > CMakeLists.txt as a sole source of project configuration. 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 want to know which files are part of the project and which are part > of the current build. > > At least Qt Creator does not need information on which conditions to > be met for a file to become part of the current build. Ok, good feedback, thanks. Steve. -- 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
