On 2023/09/03 15:58, Jonathan Schleifer wrote:
> This would be small enough if the package still built. Moving
> > SHARED_LIBS to 0.0 I get:
> >
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0
> > does not exist
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0
> > does not exist
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0
> > does not exist
>
> Ah, so the problem here was different definitions of soname. For me, the
> .0.0 is part of the soname, so it is indeed part of the soname after all (if
> going by my definition).
>
> > at make package time. This is what Stuart meant when he said that the
> > port should be in control: SHARED_LIBS should decide the version used to
> > build and install the shared libraries.
>
> So in plain English: OpenBSD wants to ignore upstream library version /
> soname versions and always use its own. Got it.
yep, exactly. reasons:
- we find that some upstream projects don't understand shared library
versioning, and either increment the version number when not needed, or
don't increment when it is needed. as this information is used to trigger
updates of packages depending on a library after that library has
changed incompatibly, it needs to work otherwise people get mismatching
library+other packages.
- in the past (rarely) we've had to bump library versions in ports after
a major incompatible change in system headers/libraries
I think we're unlikely to use this second reason again, we have a
different mechanism to force updates of all ports which is more
convenient now, but even ignoring that the first reason is enough.
and considering that when a port is brought into OpenBSD the upstream
library version is often >0.0, making sure that ports start with 0.0
means that we can check that ports is indeed in control of the version
number.
> > - .SILENT doesn't help understanding what is going on
> The non-.SILENT output isn't too useful either, as that's just a bunch of
> shellscript then that loops over things.
> > and I wonder about two things:
> > - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
> You mean because Clang is guaranteed to support ObjC?
> > - is this framework already used by other applications in the wild?
> I'm at least fairly certain not by anything else in OpenBSD ports ;).
> > Could it be used as a building block for other ports?
> Define building blocks. Like a Makefile template for other ports? I don't
> think so, it's just a regular library, users of the library can use whatever
> build system they want.
> > Do we have to
> > care about some existing ports automatically picking it up?
> I don't think so, no.
> > That's a lot of questions, sorry :)
>
> No worries, I hope I addressed everything with the new tarball I attached.
comments on the makefile:
: COMPILER= base-clang ports-clang
: COMPILER_LANGS = objc
objc is not supported by the COMPILER/COMPILER_LANGS framework; from
bsd.port.mk(5):
COMPILER_LANGS
The value of COMPILER_LANGS will be added to the respective
module's supported langs. Defaults to ‘c c++’. Only ‘c’ and
‘c++’ are supported by this mechanism. ‘fortran’ or ‘java’ still
need old modules annotations, so that it's possible to select,
e.g., ‘gfortran’ from gcc 8 while having clang from base. See
also CHOSEN_COMPILER.
: LIBOBJFW_VERSION_MAJOR = 0
: LIBOBJFW_VERSION_MINOR = 0
: LIBOBJFWRT_VERSION_MAJOR = 0
: LIBOBJFWRT_VERSION_MINOR = 0
: LIBOBJFWTLS_VERSION_MAJOR = 0
: LIBOBJFWTLS_VERSION_MINOR = 0
:
: SHARED_LIBS += objfw ${LIBOBJFW_VERSION_MAJOR}.${LIBOBJFW_VERSION_MINOR}
: SHARED_LIBS += objfwrt
${LIBOBJFWRT_VERSION_MAJOR}.${LIBOBJFWRT_VERSION_MINOR}
: SHARED_LIBS += objfwtls
${LIBOBJFWTLS_VERSION_MAJOR}.${LIBOBJFWTLS_VERSION_MINOR}
...
: MAKE_FLAGS += OBJFW_LIB_MAJOR=${LIBOBJFW_VERSION_MAJOR}
: MAKE_FLAGS += OBJFW_LIB_MINOR=${LIBOBJFW_VERSION_MINOR}
: MAKE_FLAGS += OBJFWRT_LIB_MAJOR=${LIBOBJFWRT_VERSION_MAJOR}
: MAKE_FLAGS += OBJFWRT_LIB_MINOR=${LIBOBJFWRT_VERSION_MINOR}
: MAKE_FLAGS += OBJFWTLS_LIB_MAJOR=${LIBOBJFWTLS_VERSION_MAJOR}
: MAKE_FLAGS += OBJFWTLS_LIB_MINOR=${LIBOBJFWTLS_VERSION_MINOR}
this can be simplified
SHARED_LIBS += objfw 0.0
SHARED_LIBS += objfwrt 0.0
SHARED_LIBS += objfwtls 0.0
MAKE_FLAGS += OBJFW_LIB_MAJOR=${LIBobjfw_VERSION:R} \
OBJFW_LIB_MINOR=${LIBobjfw_VERSION:E} \
OBJFWRT_LIB_MAJOR=${LIBobjfwrt_VERSION:R} \
OBJFWRT_LIB_MINOR=${LIBobjfwrt_VERSION:E} \
OBJFWTLS_LIB_MAJOR=${LIBobjfwtls_VERSION:R} \
OBJFWTLS_LIB_MINOR=${LIBobjfwtls_VERSION:E}
: MASTER_SITES1 = https://github.com/ObjFW/ObjFW/commit/
please don't do this, patches straight from github are fragile and
easily change e.g. when the shortened commit hash is no longer unique
they add an extra hex digit.
if you must fetch a patch from elsewhere please use a static file rather
than an on-the-fly generated one, but preferably include the patches in
the port (copy the original files with an .orig.port suffix in the work
directory and apply patches, then run "make update-patches" to generate
files with the correct format and filename conventions)
