On Sun, Sep 03 2023, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> On Sun, Sep 03 2023, Jonathan Schleifer <js-openbsd-po...@nil.im> 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).
>
> Not sure we have the same definition indeed. objfw indeed seems to
> use -Wl,-soname but not on OpenBSD (which is fine), so the resulting
> library doesn't have a DT_SONAME dynamic tag and the versioning
> information available to ld.so(8) only comes from the major.minor
> version encoded in the library file name.
>
>>> 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.
>
> Basically, yes.
>
>>> For automake or cmake ports this
>>> is usually handled transparently by the ports infrastructure, which sets
>>> various values in the build environment. Here you don't seem to use
>>> automake so you're probably going to need patches + ${SUBST_CMD} to inject
>>> LIBobjfw_VERSION etc at the right spot.
>>
>> Ah, perfect, this can just be overridden using MAKE_FLAGS. Done.
>
> Thanks. See the attached port for a more
>
>>> Regarding the port, I see two nits:
>>> - Portable -> portable in COMMENT
>> Done
>>> - maybe include your full name in MAINTAINER
>> Done
>>> - .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.
>
> I don't know which of .SILENT or make -s or the escape characters hide
> the compiler command lines used to build the object files, but let's
> find a way to disable this behaviour at least in the port. We need to
> see the programs and flags involved, if only to verify that said flags
> are sane in the context of the ports tree.
>
>>> and I wonder about two things:
>>> - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
>> You mean because Clang is guaranteed to support ObjC?
>
> Yup. Also the ports infrastructure doesn't seem to do much with
> COMPILER_LANGS=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 being used as an alternative for other objc frameworks and as
> a runtime for objc applications. Admittedly that's not an ecosystem
> I know much about.
>
>> 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.
>
> Thanks. Updated tarball attached which simplifies SHARED_LIBS handling
> and zaps COMPILER_LANGS=objc. Could you please tweak/patch the port so
> that compiler/linker commands are printed?Woops...
objfw-2.tar.gz
Description: Binary data
-- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
