[CMake] Recommandations for public custom macro/functions installation

Eric Noulard eric.noulard at gmail.com
Tue Apr 17 08:09:50 EDT 2018


2018-04-17 11:58 GMT+02:00 David Demelier <markand at malikania.fr>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180417/ee4fb395/attachment.html>


More information about the CMake mailing list