feature request: add an option and support for build, use, and install a dynamic library too

[ClausKlein]

concept is shown at https://crascit.com/2019/10/16/cppcon-2019-deep-cmake-for-library-authors/

for a demo implementations see #83

[friendlyanon]

This request has great value proposition. Creating libraries that can be built as both static and shared is something that a lot of people get wrong. Recently, I had to correct some Boost people in the cpplang slack regarding this topic, so this issue affects developers of every skill level. The reason for this is simply that the language itself and the surrounding systems are two entirely separate worlds.

@TheLartians I have a repository that is a sort of tutorial to show how creating such a library that can be built as both static and shared has to take into consideration and what code has to be present in the CML of the project. You can find this project here: https://github.com/friendlyanon/cxx-static-shared-example
I feel like this could be a tricky thing to add to this starter project, as it tries to be generic. I'm curious what you think with this above information at your disposal.

[TheLartians]

One thing I worry about if the extra complexity is actually worth it for "regular" projects built using the starter or if this is more a "niche" feature. From my personal experience (which may be completely off ¯\_(ツ)_/¯), shared libraries are used very far down the line and not usually a requirement relevant to 99% of new projects or single-purpose libraries. I feel that too much initial complexity could make the starter unattractive to new users.

That said, it seems like something that should be made as easy as possible to add later on and that would be useful to be documented somewhere in the starter.

[friendlyanon]

Echoing what I said in TheLartians/PackageProject.cmake#19 (comment), I would add a function to this project that generates the export header and sets up the target with the necessary properties, and maybe that function could interact in a nice way with PackageProject.cmake.

[Leon0402]

Maybe it would be best to create two templates?

Based on my experience the requirements for a cpp starter template to create an executable are quite different to building a library.

For a library:

• Deal with shared / static
• Deal with different setups: find_package, fetchContent and stuff
• Correctly propagate things the user of lib needs (Use of INTERFACE / PUBLIC where approriate), but don't set things that one doesn't need (globally set some variables and stuff)
• How to include libs the right way -> Leavin the user the choice to overwrite or provide a dependency a different way (For instance rather not hardcode find_package)
• ....

For an exectuable:

• How to include libs the various way
• How to configure Libs with FetchContent and how to fix libs with FetchContent if they have not followed best practice
• How to package exectuable with cpack and stuff
• ...

I just think the requirements are rather different and it's best to create two templates

[friendlyanon]

I just think the requirements are rather different and it's best to create two templates

That is indeed correct. One of the reasons I created cmake-init, among many other things.

[Leon0402]

I just think the requirements are rather different and it's best to create two templates

That is indeed correct. One of the reasons I created cmake-init, among many other things.

Oh that's quite nice! I think this is the right step in the right direction. An init script allows the flexibility one needs with cmake!

[onqlave-cesc]

How I can you cmake-init for existing project like libsodium?