Changes between Initial Version and Version 1 of Ticket #63428, comment 2


Ignore:
Timestamp:
Sep 2, 2021, 3:21:13 PM (3 years ago)
Author:
ryandesign (Ryan Carsten Schmidt)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #63428, comment 2

    initial v1  
    11In MacPorts, a "variant" is a method by which a user can select which optional features of a port they want to install. "port variants foo" shows you the available variants of the port named "foo". We create variants sparingly. We want ports to have good defaults that match the needs of most users. Variants are only added when there are heavy optional features that most users would not want, or when the user may want to choose between multiple conflicting options, such as which branch of python the port should use.
    22
    3 Ports that install libraries that are intended to be used by others should always install dynamic libraries. Ports that link with other ports' libraries generally do so by dynamic linking. In most ports using the autotools build system, installing both dynamic and static libraries is the default, and if it is not the default, then it can usually be enabled with a simple configure flag (`--enable-static` and/or `--enable-shared`, whichever one(s) are not enabled by default in that project). This fact is probably why in MacPorts we recommend that ports should also install static libraries if possible, in case a user wants to use them for their own purposes. Unfortunately, other newer build systems, notably cmake, require the user to [https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html decide whether to build dynamic or static libraries] and do not offer the ability to do both at once (unless the individual project that uses cmake has added custom code to their CMakeLists.txt to completely bypass the standard cmake way of creating libraries, and I can only think of one project that has done that (mongo-c-driver)). Therefore, ports that build using cmake can only install dynamic libraries. openimageio builds using cmake. Therefore it probably can only offer dynamic libraries, not static libraries.
     3Ports that install libraries that are intended to be used by others should always install dynamic libraries. Ports that link with other ports' libraries generally do so by dynamic linking. In most ports using the autotools build system, installing both dynamic and static libraries is the default, and if it is not the default, then it can usually be enabled with a simple configure flag (`--enable-static` and/or `--enable-shared`, whichever one(s) are not enabled by default in that project). This fact is probably why in MacPorts we recommend that ports should also install static libraries if possible, in case a user wants to use them for their own purposes. Unfortunately, other newer build systems, notably cmake, require the user to [https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html decide whether to build dynamic or static libraries] and do not offer the ability to do both at once (unless the individual project that uses cmake has added custom code to their CMakeLists.txt to completely bypass the standard cmake way of creating libraries, and I can only think of one project that has done that (mongo-c-driver)). Therefore most ports that build using cmake can only install dynamic libraries. openimageio builds using cmake, therefore it probably can only offer dynamic libraries, not static libraries.
    44
    55We would never offer variants for whether a port should install static or dynamic libraries. That would be giving users an opportunity to shoot themselves in the foot, and we try not to offer those opportunities. Consider port libao which offers an audio library called libao.4.dylib and which does not currently install a static library. Other ports in MacPorts that use libao link with libao.4.dylib. If we were to offer conflicting static and dynamic variants, then a user might install the port with the static variant instead of the dynamic variant. The port would then install libao.a but not libao.4.dylib, and that would break all of the ports that link with libao.4.dylib, and we don't want that.