Re: [CMake] Recommandations for public custom macro/functions installation
On Dienstag, 17. April 2018 13:48:39 CEST David Demelier wrote: > On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > > Just replying to this topic of your message: you may want to > > reconsider. The > > cmake gui allows you to group options automatically by prefix. This > > de-clutters > > the options considerably. > > I didn't know that! Nice catch. I'll reconsider using prefix then. I've > usually named my options WITH_FOO, do you recommend to use > PROJECT_WITH_FOO or WITH_PROJECT_FOO then? Personally, I prefer PROJECT_WITH_FOO because it also works when I have additional options PROJECT_ADDITIONAL_OPTION... Cheers, Johannes -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommandations for public custom macro/functions installation
2018-04-17 11:58 GMT+02:00 David Demelier : > Hello, > > In my application I have some custom functions that help the process of > creating executable, libraries, plugins and such. > > They don't do magic things but they mostly build, provide installation > to specific place and optionally build the documentation and install > them as well. This happens in my project. Since the project is > extensible, I want to install the libraries **and** those macros so > users will be able to use them so their plugins get installed in the > correct place alongside the documentation without much effort. > > Example, the user will just write: > > irccd_define_plugin( > SOURCES main.cpp > DOCS myplugin.md > ) > > The problem with that macro, is that it has a conditional to build the > documentation depending on an option. This is fine in my project since > the user may build or not build the documentation by setting WITH_DOCS > to Off. > Now I wonder how I should handle this option when the macro is > publicliy installed. The most problematic question is that variables do > not have namespaces so if the user of my macro also have an option > WITH_DOCS in its own CMakeLists.txt, this will interfer with the > installed macro. > Add an optional BUILD_DOCS option parameter to your macro with default to "False" if not present so that user cannot call it without knowing. i.e. You will call: irccd_define_plugin( SOURCES main.cpp DOCS myplugin.md BUILD_DOCS ${WITH_DOC} ) your user may safely call: irccd_define_plugin( SOURCES main.cpp DOCS userplugin.md ) Another option would be to carry "doc generation option" as a target level custom property you can attach to each target (exe, plugins , etc...) created by your macro. Then your macro may decide to generate doc iff the chosen property is defined on a per-target basis. -- Eric -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommandations for public custom macro/functions installation
On Tue, Apr 17, 2018 at 9:48 PM, David Demelier wrote: > On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > > Just replying to this topic of your message: you may want to > > reconsider. The > > cmake gui allows you to group options automatically by prefix. This > > de-clutters > > the options considerably. > > I didn't know that! Nice catch. I'll reconsider using prefix then. I've > usually named my options WITH_FOO, do you recommend to use > PROJECT_WITH_FOO or WITH_PROJECT_FOO then? > Definitely go with PROJECT_WITH_FOO. Only the letters up to the first underscore are used for the grouping in cmake-gui. For larger hierarchical projects, this grouping feature is pretty important if you want any chance of keeping the variables manageable in the GUI. The project-specific prefix is also good protection against name clashes with other parts of the build (always consider the possibility that your project may one day be used as part of some larger parent project, pulled in by add_subdirectory()). -- Craig Scott Melbourne, Australia https://crascit.com -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommandations for public custom macro/functions installation
On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > Just replying to this topic of your message: you may want to > reconsider. The > cmake gui allows you to group options automatically by prefix. This > de-clutters > the options considerably. I didn't know that! Nice catch. I'll reconsider using prefix then. I've usually named my options WITH_FOO, do you recommend to use PROJECT_WITH_FOO or WITH_PROJECT_FOO then? -- David -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommandations for public custom macro/functions installation
Hi David, On Dienstag, 17. April 2018 11:58:12 CEST David Demelier wrote: > I personally do not want to prefix all my options in my project with > the project name prefix, I think that would be a bit ugly, and I do > want this macro to build and install the documentation. Just replying to this topic of your message: you may want to reconsider. The cmake gui allows you to group options automatically by prefix. This de-clutters the options considerably. On a related note: even without grouping, looking through the options of a project in ccmake or cmake-gui is so much easier when they are prefixed (and therefore easily identifiable). Cheers, Johannes -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] Recommandations for public custom macro/functions installation
Hello, In my application I have some custom functions that help the process of creating executable, libraries, plugins and such. They don't do magic things but they mostly build, provide installation to specific place and optionally build the documentation and install them as well. This happens in my project. Since the project is extensible, I want to install the libraries **and** those macros so users will be able to use them so their plugins get installed in the correct place alongside the documentation without much effort. Example, the user will just write: irccd_define_plugin( SOURCES main.cpp DOCS myplugin.md ) The problem with that macro, is that it has a conditional to build the documentation depending on an option. This is fine in my project since the user may build or not build the documentation by setting WITH_DOCS to Off. Now I wonder how I should handle this option when the macro is publicliy installed. The most problematic question is that variables do not have namespaces so if the user of my macro also have an option WITH_DOCS in its own CMakeLists.txt, this will interfer with the installed macro. What are your recommandations over this? I personally do not want to prefix all my options in my project with the project name prefix, I think that would be a bit ugly, and I do want this macro to build and install the documentation. Any advice/comment is welcome. Regards, -- David -- 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: https://cmake.org/mailman/listinfo/cmake