[question] Build both static and dynamic versions of the library
According to the wiki, build option BUILD_SHARED_LIBS permits to select between static and dynamic versions of the library to build. Is there any way to build at the same time (without re-configuring the build) the both versions? I want to create a FreeBSD port of the library (it works correctly under FreeBSD), and I would like to install both versions by default.
preferred way would be to run cmake configure/build twice i think.
@kikaxa No problems to do like this in case of a manual build. But it is impossible in case of automatic build (package). Normally one build is started, it should provide everything to pack.
static version is only usable for devs(vs dynamic being used by other packages), and should be a separate -dev pkg imo. you can specify dependencies to install one/both as needed
..for c++ project dependency management, i would recommend using dev/language specific dependency/package managers, as opposed to system. e.g. submodules, cpm/vcpkg/conan etc
@kikaxa Sorry, you explain Linux packaging approach. I work with FreeBSD, it's different. There is no xxxx-dev packages there. Yes, I would like to use Conan, but this library is not present there.
there certainly is dev packages.
The screenshot shows two different ports. Yes, it is a possible approach - create two different ports with different build options, each one would produce a package with different content. Then, it is important to manage conflicts. For example, if I have an installed package (or several packages) that depends on non-dev version, and I want to build a software that needs a dev version - I need to uninstall the non-dev version and all dependent packages. To avoid this - the filenames in two packages should be different (or two packages install different set of files). IMHO, build both versions of the library is mush more simple. This is an approach used in (almost) all libraries ports.
can you provide a sample pkg (preferable cmake-) portsfile that does that? if it is common and clean, i see no problem implementing that