Re: [cmake-developers] Optional dependencies in target INTERFACE
Stephen Kelly writes: > Hello, > > QtSQL provides abstracted access to database data. It does not depend on > QtGui or QtWidgets. > > It also provides the header-only qsqlrelationaldelegate.h. The contents of > that header depend on QtWidgets, and are wrapped in an ifdef QT_WIDGETS_LIB. > That means that the QSqlRelationalDelegate class is only available if that > macro is defined, which is an effect of linking to Qt5Widgets anyway. This > seems to be a good and well-working way to have an optional INTERFACE > dependency. > > Unfortunately most projects do not have something similar to QT_WIDGETS_LIB > macros. > > If a target is only a dependency if the depender uses a particular header, > then should that target appear in the INTERFACE_LINK_LIBRARIES? If using > QtGui but not using #include you do not depend on the GL > libraries. If you add that include, you do depend on the GL libraries. Do > the GL libraries belong in the INTERFACE_LINK_LIBRARIES of QtGui? That is > the subject of > > https://bugreports.qt-project.org/browse/QTBUG-39859 > > In the case of modularized-Boost header-only libraries with INTERFACE > targets, what criteria should be used to determine whether to put a > dependency in the INTERFACE_LINK_LIBRARIES and make component packages? The > actual dependencies required are determined by what the user #includes, not > by what headers are #included by 'my' headers. I use an approach similar to Daniel in my projects and never encode optional dependencies. Each component or optional third party library always comes with a define to notify other headers that it is available. Maybe as a convenience another intermediate interface or alias target could be added such as Boost::library_use_other_library. Some Boost libraries also provide anti-feature macros and we could enable them by default and disable them through the optional dependency, so you always have to explicitly enable a dependency. Although I don't see how this can be expressed easily through targets. -- 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
Re: [cmake-developers] Broken progress output with make -jXX (aka parallel make)
On 06/27/2014 04:32 PM, Adam Strzelecki wrote: > As you probably notice percentage is decoupled by rest of status line. This was reported here: http://www.cmake.org/Bug/view.php?id=12991 but it hasn't bothered anyone enough to fix it. -Brad -- 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
Re: [cmake-developers] [PATCH 1/3] Ninja: Consider only custom commands deps as side-effects (#14972)
On 06/27/2014 04:13 PM, Adam Strzelecki wrote: > Previously all explicit dependencies inside build folder were considered as > possible build command side-effects and phony rules were produced for them in > case they don't exist yet starting build. This however incorrect since regular > compile inputs need to exist otherwise cmake will fail. Moreover the exception > for sources having GENERATED property that can be missing is already handled > by > WriteAssumedSourceDependencies. Thanks! I've applied this series with minor tweaks to coding style and the commit messages: Ninja: Consider only custom commands deps as side-effects (#14972) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a33cf6d0 Ninja: Don't limit custom cmd side-effects to build folder (#14972) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7243c951 Ninja: Skip generating empty phony rules http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93371ed5 -Brad -- 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
Re: [cmake-developers] Optional dependencies in target INTERFACE
2014-06-30 10:18 GMT+02:00 Stephen Kelly : > > Hello, > > QtSQL provides abstracted access to database data. It does not depend on > QtGui or QtWidgets. > > It also provides the header-only qsqlrelationaldelegate.h. The contents of > that header depend on QtWidgets, and are wrapped in an ifdef > QT_WIDGETS_LIB. > That means that the QSqlRelationalDelegate class is only available if that > macro is defined, which is an effect of linking to Qt5Widgets anyway. This > seems to be a good and well-working way to have an optional INTERFACE > dependency. > > Unfortunately most projects do not have something similar to QT_WIDGETS_LIB > macros. > > If a target is only a dependency if the depender uses a particular header, > then should that target appear in the INTERFACE_LINK_LIBRARIES? If using > QtGui but not using #include you do not depend on the GL > libraries. If you add that include, you do depend on the GL libraries. Do > the GL libraries belong in the INTERFACE_LINK_LIBRARIES of QtGui? That is > the subject of > > https://bugreports.qt-project.org/browse/QTBUG-39859 > > In the case of modularized-Boost header-only libraries with INTERFACE > targets, what criteria should be used to determine whether to put a > dependency in the INTERFACE_LINK_LIBRARIES and make component packages? The > actual dependencies required are determined by what the user #includes, not > by what headers are #included by 'my' headers. > ... or what the user uses *in addition*. When my project depends on Boost.UUID but not on Boost.Serialization, then I certainly don't need the optional serialization support of UUIDs. If I want to use serialization, then Boost.Serialization has to be a direct dependency of my project as I need to #include some of its headers directly. I conclude that the optional dependency from Boost.UUID to Boost.Serialization does not have to be represented at all. Does that make sense? -- Daniel -- 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
[cmake-developers] Optional dependencies in target INTERFACE
Hello, QtSQL provides abstracted access to database data. It does not depend on QtGui or QtWidgets. It also provides the header-only qsqlrelationaldelegate.h. The contents of that header depend on QtWidgets, and are wrapped in an ifdef QT_WIDGETS_LIB. That means that the QSqlRelationalDelegate class is only available if that macro is defined, which is an effect of linking to Qt5Widgets anyway. This seems to be a good and well-working way to have an optional INTERFACE dependency. Unfortunately most projects do not have something similar to QT_WIDGETS_LIB macros. If a target is only a dependency if the depender uses a particular header, then should that target appear in the INTERFACE_LINK_LIBRARIES? If using QtGui but not using #include you do not depend on the GL libraries. If you add that include, you do depend on the GL libraries. Do the GL libraries belong in the INTERFACE_LINK_LIBRARIES of QtGui? That is the subject of https://bugreports.qt-project.org/browse/QTBUG-39859 In the case of modularized-Boost header-only libraries with INTERFACE targets, what criteria should be used to determine whether to put a dependency in the INTERFACE_LINK_LIBRARIES and make component packages? The actual dependencies required are determined by what the user #includes, not by what headers are #included by 'my' headers. 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
Re: [cmake-developers] IMPORTED targets for some Find modules
Stephen Kelly wrote: >> If you build a library using foo.cpp it will contain the glVertex2i >> symbol even though its headers wont include it. Likewise a consumer of >> that library does not need to have the headers, > >> but will need to link against a library containing the symbol. > > Ah, I guess we're talking about static libraries here. Given this, you might consider wrapping the dependencies in $ in the INTERFACE. That would match the behavior of cmExportFileGenerator I think. 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
