Recommandations for public custom macro/functions installation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Recommandations for public custom macro/functions installation

David Demelier-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Recommandations for public custom macro/functions installation

Johannes Zarl-Zierl
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
Reply | Threaded
Open this post in threaded view
|

Re: Recommandations for public custom macro/functions installation

David Demelier-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Recommandations for public custom macro/functions installation

Craig Scott-3


On Tue, Apr 17, 2018 at 9:48 PM, David Demelier <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Recommandations for public custom macro/functions installation

Eric Noulard
In reply to this post by David Demelier-2


2018-04-17 11:58 GMT+02:00 David Demelier <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: Recommandations for public custom macro/functions installation

Johannes Zarl-Zierl
In reply to this post by David Demelier-2
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