Re: [CMake] Recommandations for public custom macro/functions installation

[Johannes Zarl-Zierl]

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

[Eric Noulard]

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

[Craig Scott]

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

[David Demelier]

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

[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

[CMake] Recommandations for public custom macro/functions installation

[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.

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