Marc and Steven,
thanks a lot, this was incredibly helpful.
steven mestdagh wrote:
SHARED_LIBS simply enumerates the shared libraries and their version
numbers. In doing so, it sets a few variables to be used by libtool (or
other build utilities, that may or may not have to be patched to use
those variables) and pkg_create in PFRAG.shared. This doesn't actually
do very much on its own just yet, other than supplying said variables
that happen to be in a format that libtool likes.
SHARED_LIBS is used to _control_ the versions of all shared libraries
that a port installs. Indeed it sets variables like LIBfoo_VERSION that
you can pass where needed. The important thing is you fix the build so
that you control the version numbers through SHARED_LIBS.
Yes, understood. Just to confirm, you should've emphasized "used"
instead of "control" to be uber-nitpickingly correct, right? SHARED_LIBS
does nada automagically, but we /want/ to be able to control the version
numbers with it, i.e. use it.
You should always test changing the version numbers in SHARED_LIBS.
make update-plist will complain if they do not match the versions that
the port is actually installing.
Sounds like a candidate for http://www.openbsd.org/checklist.html and/or
http://www.openbsd.org/porttest.html ... maybe once this has settled
(wrt Marc being unhappy about _ALIAS) and is documented in bsd.port.mk(5).
One final question: One of my ports, net/libshout, uses ``-version-info
4:0:1'' -- SHARED_LIBS only handles what libtool calls CURRENT (major)
and REVISION version numbers, not the AGE (patch-level?) thing. This is
probably not a big deal, however, when SHARED_LIBS'ifying a port, should
the new version be 4.0 (4:0:0, effectively a downgrade ... doesn't sound
good) or 4.1 (4:1:0) or 5.0 (5:0:0)? I'm betting on "4.1", or are we
always bumping major .so version numbers?
Moritz
