[MacPorts] #63428: openimageio: Also install static libraries (was: No static variant of openimageio)

[MacPorts]

#63428: openimageio: Also install static libraries
--------------------------+---------------------------------
  Reporter:  MarkCallow   |      Owner:  MarcusCalhoun-Lopez
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  openimageio  |
--------------------------+---------------------------------
Changes (by ryandesign):

 * type:  defect => enhancement


Comment:

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

 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.

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

 A global solution to the problem of cmake only offering static or dynamic
 libraries would be to redesign the cmake portgroup so that it performs the
 entire configuration and build process twice: once for static libraries, a
 second time for dynamic libraries. This would be a big redesign of the
 cmake portgroup which would have the potential to introduce new bugs in
 the portgroup code or to reveal ways in which any of the hundreds of ports
 that already use the cmake portgroup are not compatible with that change.
 Testing those hundreds of ports after such a change would take a very long
 time, and committing the change without testing it thoroughly could just
 end up pushing undiscovered problems onto users. Even if there are no bugs
 and everything works correctly, running two configurations and builds
 instead of one will make builds slower. Also, not all ports that use the
 cmake build system use the cmake portgroup; those that don't would not
 benefit from the improvement. We do already have two different versions of
 the cmake portgroup and ports can decide which one to use. We could
 introduce the redesign in a new third version of the portgroup and ports
 could opt in to it over time as time permits. As far as I know, nobody has
 yet begun to work on such a redesign. A different approach could be to
 work with the developers of cmake to get them to offer an option to build
 both types of libraries in a single build. I haven't looked if anyone has
 yet proposed such a thing.

 Since modifying the port to offer static libraries is going to be a
 problem, let's focus on what you actually need. You can use dynamic
 libraries from your program. If it were a normal app bundle, it would be a
 trivial matter of placing the libraries into a directory within your app
 bundle's Contents directory and changing the libraries' install names (and
 the references to them in your program) to use @executable_path. The
 dylibbundler program, installable via the dylibbundler port, automates
 these tasks for you. I'm not familiar with the process of signing, but I'm
 assuming that's not an insurmountable obstacle. If your program is just a
 command line program without an app bundle, that's not as nicely
 contained, but you can still create a directory at any path relative to
 where your program is installed, put the libraries in there, and
 dynamically link to them. Installing standalone software into
 /opt/<programname> is common, so if your program is called foo, then it
 could be reasonable for your installer to install your program at
 /opt/foo/bin/foo and its copies of libopenimageio and other libraries in
 /opt/foo/lib. If you use @executable_path, either manually or using
 dylibbundler, then the user can move or rename /opt/foo as desired.
 Another option that as far as I know Apple recommends would be for you to
 put your command line program and its libraries into an app bundle anyway.
 Many apps I have installed come with command line programs and libraries
 within their bundle. I don't think I've encountered one that's just a CLI
 without a GUI, but presumably there could be a way for you to write a very
 small GUI program that does nothing other than display a dialog referring
 the user to documentation about how to use the CLI, so that something
 useful happens if the user double-clicks your app.

-- 
Ticket URL: <https://trac.macports.org/ticket/63428#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS