Re: New port: devel/objfw
Am 05.09.23 um 12:50 schrieb Stuart Henderson: Except it isn't robust to changes - it can just silently fail to apply, which doesn't happen with a patch. My worry was that a patch still applies and misses to remove an -s, then giving you only partial output, which is worse than no output. In any case, that won't be a concern. The buildsys now supports --disable-silent-rules (https://fl.nil.im/buildsys/info/182a6b6bca378d8c) and this will be in the next release (https://objfw.nil.im/info/9e971288b972f330). -- Jonathan
Re: New port: devel/objfw
On 2023/09/04 22:52, Jonathan Schleifer wrote: > Am 04.09.23 um 16:30 schrieb Jeremie Courreges-Anglas: > > > Thanks. I have imported objfw as proposed in your last tarball, except > > with a simple patch for clarity instead of your ed(1) script. > > Thank you! > > My reason for using the ed script over a patch was that it'll be > more robust to changes. I'll see if I can add a general > `--disable-silent-rules` or something. Except it isn't robust to changes - it can just silently fail to apply, which doesn't happen with a patch.
Re: New port: devel/objfw
Am 04.09.23 um 16:30 schrieb Jeremie Courreges-Anglas: Thanks. I have imported objfw as proposed in your last tarball, except with a simple patch for clarity instead of your ed(1) script. Thank you! My reason for using the ed script over a patch was that it'll be more robust to changes. I'll see if I can add a general `--disable-silent-rules` or something. -- Jonathan
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jonathan Schleifer wrote: > Am 03.09.23 um 19:49 schrieb Jeremie Courreges-Anglas: > >> 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. > > Attached is an updated port that removes the silent rules. However, that > makes the output quite confusing and is IMO not really an improvement. > But hey, you're the guys looking at that output, if that's what you > prefer, I'm fine with that :-). > >> 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. > > If that's all: buildsys.mk is the source of truth for all that. Printing > OBJC, OBJCFLAGS, CPPFLAGS, LIBS and LDFLAGS from that would probably be > sufficient for that purpose and would look a lot less messy. There are two colliding interests here: having a build log that looks neat to you or the end user (hence the ascii escape sequences, I guess), and explicit build logs that bring us porters valuable information. There are few things as frustrating for us as an opaque build system. The output may look a bit messy in the port, but in that context that's better than no output at all. If that's something you want to care about, many projects handle both wishes with a --disable-silent-rules or V=0/V=1 button. >> 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. > > Nope, this is not an OpenStep implementation, so cannot act as the > alternative of one. ack >> 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? > > I took those two changes. For silent see above. Thanks. I have imported objfw as proposed in your last tarball, except with a simple patch for clarity instead of your ed(1) script. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: New port: devel/objfw
On 2023/09/03 20:48, Jonathan Schleifer wrote: > Am 03.09.23 um 19:49 schrieb Jeremie Courreges-Anglas: > > > 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. > > Attached is an updated port that removes the silent rules. However, that > makes the output quite confusing and is IMO not really an improvement. But > hey, you're the guys looking at that output, if that's what you prefer, I'm > fine with that :-). we often aren't looking at the output directly, rather grepping the build logs looking for software using e.g. certain headers / compiler flags / etc.
Re: New port: devel/objfw
Am 03.09.23 um 19:55 schrieb Stuart Henderson: 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. Upstream handling reads exactly like OpenBSD handling, so this case is probably fine. (minor increased for new symbols, major increased on ABI break) 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. I guess since the second case is unlikely, in practice, OpenBSD's version will always be one major version less than upstream. But hey, if that is required to show "we're using OpenBSD library versions here and not upstream versions", so be it. My concern is just someone having it installed without ports on OpenBSD - and then there is a lot of fun with library versions being exactly one major version apart. Seems like asking for trouble on systems where you have both, ports and non-ports versions. 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) I realized that patch is not needed at all, as both versions are 1.0 in this release. Only in the future, when they diverge, such a patch would be required. However, any future release will already include the patch, so, including it is not necessary and just setting the variables like it already were will just magically make it work with the next update. -- Jonathan
Re: New port: devel/objfw
Am 03.09.23 um 19:49 schrieb Jeremie Courreges-Anglas: 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. Attached is an updated port that removes the silent rules. However, that makes the output quite confusing and is IMO not really an improvement. But hey, you're the guys looking at that output, if that's what you prefer, I'm fine with that :-). 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. If that's all: buildsys.mk is the source of truth for all that. Printing OBJC, OBJCFLAGS, CPPFLAGS, LIBS and LDFLAGS from that would probably be sufficient for that purpose and would look a lot less messy. 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. Nope, this is not an OpenStep implementation, so cannot act as the alternative of one. 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? I took those two changes. For silent see above. PTAL. -- Jonathan objfw.tar.gz Description: application/gzip
Re: New port: devel/objfw
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
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jeremie Courreges-Anglas wrote:
> On Sun, Sep 03 2023, 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).
>
> 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
Re: New port: devel/objfw
On Sun, Sep 03 2023, 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).
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?
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: New port: devel/objfw
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.
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.
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.
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.
--
Jonathan
objfw.tar.gz
Description: application/gzip
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jonathan Schleifer wrote:
> Am 03.09.23 um 12:55 schrieb Jeremie Courreges-Anglas:
>
>> On Sun, Sep 03 2023, Jonathan Schleifer wrote:
>>> Am 31.08.23 um 09:56 schrieb Jonathan Schleifer:
>>>
Am 31.08.23 um 08:26 schrieb Stuart Henderson:
>>> SHARED_LIBS += objfw 1.0
>>> SHARED_LIBS += objfwrt 1.0
>>> SHARED_LIBS += objfwtls 1.0
>> I can't remember how strict we are with these version starting numbers
>> but iirc we start with 0.1 (?) I don't really mind if this isn't
>> changed.
>> The bumpings are the more important ones anyway.
> 0.0.
>
> The key thing is to make sure that changing the versions in SHARED_LIBS
> changes the versions of the produced file, i.e. make sure that ports is
> in control.
Ok, now I have questions :).
I was under the impression that the the SHARED_LIBS should match the
.so name? This would be the case with 1.0, as upstream used 0.0 during
development when there was no stable ABI/API (and users could have
installed such a pre-1.0 release manually on OpenBSD). I could find
https://man.openbsd.org/library-specs.7 which seems to indicate it
must match the .so name, as well as lining out rules on when and how
to update the version, which match upstream in this case (I can vouch
for this, as I am the upstream).
Given that, wouldn't it be better to have it 1.0 instead of always one
major version less than upstream?*
* Very, very early, there was a major version of as high as 8. But
this was a decade or so ago and I think nobody ever used it. And on
a version that was very much declared "this WILL break, don't use this
for anything"
>>> I'm happy to change it to 0.0, of course, but would really like to fully
>>> understand the implications of this. Should every port, when imported to
>>> OpenBSD, change the soname to 0.0?
>> The library version should be 0.0 for a new port and the soname should
>> match the library name.
>
> Ah, OK, so then I was confused by the documentation, which I interpreted
> as it needs to match. Then I see absolutely no reason why it shouldn't
> be set to 0.0 indeed.
>
>> That's how we handle it in ports, with all due
>> respect that's not something that you, as an upstream, should feel
>> concerned about IMO.
>
> Sorry, I didn't mean to question the way you do things in OpenBSD ports,
> I was merely trying to understand if that has any implications for
> soname.
>
>> The version used in ports may stay at 0.0 or move to 0.1 or 1.0, 2.0
>> etc, it depends on how you (upstream) preserve or change API and ABI in
>> the future, but it may also depend on changes in the OpenBSD base system
>> and ports tree. That's why the port for objfw should have complete
>> control about the version used.
>
> All good then! Should I send another tarball with it set to 0.0, or is
> this small enough for whoever imports it to just do it?
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
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. 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.
Regarding the port, I see two nits:
- Portable -> portable in COMMENT
- maybe include your full name in MAINTAINER
- .SILENT doesn't help understanding what is going on
and I wonder about two things:
- COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
- is this framework already used by other applications in the wild?
Could it be used as a building block for other ports? Do we have to
care about some existing ports automatically picking it up?
That's a lot of questions, sorry :)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: New port: devel/objfw
Am 03.09.23 um 12:55 schrieb Jeremie Courreges-Anglas: On Sun, Sep 03 2023, Jonathan Schleifer wrote: Am 31.08.23 um 09:56 schrieb Jonathan Schleifer: Am 31.08.23 um 08:26 schrieb Stuart Henderson: SHARED_LIBS += objfw 1.0 SHARED_LIBS += objfwrt 1.0 SHARED_LIBS += objfwtls 1.0 I can't remember how strict we are with these version starting numbers but iirc we start with 0.1 (?) I don't really mind if this isn't changed. The bumpings are the more important ones anyway. 0.0. The key thing is to make sure that changing the versions in SHARED_LIBS changes the versions of the produced file, i.e. make sure that ports is in control. Ok, now I have questions :). I was under the impression that the the SHARED_LIBS should match the .so name? This would be the case with 1.0, as upstream used 0.0 during development when there was no stable ABI/API (and users could have installed such a pre-1.0 release manually on OpenBSD). I could find https://man.openbsd.org/library-specs.7 which seems to indicate it must match the .so name, as well as lining out rules on when and how to update the version, which match upstream in this case (I can vouch for this, as I am the upstream). Given that, wouldn't it be better to have it 1.0 instead of always one major version less than upstream?* * Very, very early, there was a major version of as high as 8. But this was a decade or so ago and I think nobody ever used it. And on a version that was very much declared "this WILL break, don't use this for anything" I'm happy to change it to 0.0, of course, but would really like to fully understand the implications of this. Should every port, when imported to OpenBSD, change the soname to 0.0? The library version should be 0.0 for a new port and the soname should match the library name. Ah, OK, so then I was confused by the documentation, which I interpreted as it needs to match. Then I see absolutely no reason why it shouldn't be set to 0.0 indeed. That's how we handle it in ports, with all due respect that's not something that you, as an upstream, should feel concerned about IMO. Sorry, I didn't mean to question the way you do things in OpenBSD ports, I was merely trying to understand if that has any implications for soname. The version used in ports may stay at 0.0 or move to 0.1 or 1.0, 2.0 etc, it depends on how you (upstream) preserve or change API and ABI in the future, but it may also depend on changes in the OpenBSD base system and ports tree. That's why the port for objfw should have complete control about the version used. All good then! Should I send another tarball with it set to 0.0, or is this small enough for whoever imports it to just do it? Thanks again! -- Jonathan
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jonathan Schleifer wrote: > Am 31.08.23 um 09:56 schrieb Jonathan Schleifer: > >> Am 31.08.23 um 08:26 schrieb Stuart Henderson: > SHARED_LIBS += objfw 1.0 > SHARED_LIBS += objfwrt 1.0 > SHARED_LIBS += objfwtls 1.0 I can't remember how strict we are with these version starting numbers but iirc we start with 0.1 (?) I don't really mind if this isn't changed. The bumpings are the more important ones anyway. >>> 0.0. >>> >>> The key thing is to make sure that changing the versions in SHARED_LIBS >>> changes the versions of the produced file, i.e. make sure that ports is >>> in control. >> >> Ok, now I have questions :). >> >> I was under the impression that the the SHARED_LIBS should match the >> .so name? This would be the case with 1.0, as upstream used 0.0 during >> development when there was no stable ABI/API (and users could have >> installed such a pre-1.0 release manually on OpenBSD). I could find >> https://man.openbsd.org/library-specs.7 which seems to indicate it >> must match the .so name, as well as lining out rules on when and how >> to update the version, which match upstream in this case (I can vouch >> for this, as I am the upstream). >> >> Given that, wouldn't it be better to have it 1.0 instead of always one >> major version less than upstream?* >> >> * Very, very early, there was a major version of as high as 8. But >> this was a decade or so ago and I think nobody ever used it. And on >> a version that was very much declared "this WILL break, don't use this >> for anything" > > I'm happy to change it to 0.0, of course, but would really like to fully > understand the implications of this. Should every port, when imported to > OpenBSD, change the soname to 0.0? The library version should be 0.0 for a new port and the soname should match the library name. That's how we handle it in ports, with all due respect that's not something that you, as an upstream, should feel concerned about IMO. Earlier you said: >> Given that, wouldn't it be better to have it 1.0 instead of always one >> major version less than upstream?* The version used in ports may stay at 0.0 or move to 0.1 or 1.0, 2.0 etc, it depends on how you (upstream) preserve or change API and ABI in the future, but it may also depend on changes in the OpenBSD base system and ports tree. That's why the port for objfw should have complete control about the version used. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: New port: devel/objfw
Am 31.08.23 um 09:56 schrieb Jonathan Schleifer: Am 31.08.23 um 08:26 schrieb Stuart Henderson: SHARED_LIBS += objfw 1.0 SHARED_LIBS += objfwrt 1.0 SHARED_LIBS += objfwtls 1.0 I can't remember how strict we are with these version starting numbers but iirc we start with 0.1 (?) I don't really mind if this isn't changed. The bumpings are the more important ones anyway. 0.0. The key thing is to make sure that changing the versions in SHARED_LIBS changes the versions of the produced file, i.e. make sure that ports is in control. Ok, now I have questions :). I was under the impression that the the SHARED_LIBS should match the .so name? This would be the case with 1.0, as upstream used 0.0 during development when there was no stable ABI/API (and users could have installed such a pre-1.0 release manually on OpenBSD). I could find https://man.openbsd.org/library-specs.7 which seems to indicate it must match the .so name, as well as lining out rules on when and how to update the version, which match upstream in this case (I can vouch for this, as I am the upstream). Given that, wouldn't it be better to have it 1.0 instead of always one major version less than upstream?* * Very, very early, there was a major version of as high as 8. But this was a decade or so ago and I think nobody ever used it. And on a version that was very much declared "this WILL break, don't use this for anything" I'm happy to change it to 0.0, of course, but would really like to fully understand the implications of this. Should every port, when imported to OpenBSD, change the soname to 0.0? -- Jonathan
Re: New port: devel/objfw
Am 31.08.23 um 08:26 schrieb Stuart Henderson: SHARED_LIBS += objfw 1.0 SHARED_LIBS += objfwrt 1.0 SHARED_LIBS += objfwtls 1.0 I can't remember how strict we are with these version starting numbers but iirc we start with 0.1 (?) I don't really mind if this isn't changed. The bumpings are the more important ones anyway. 0.0. The key thing is to make sure that changing the versions in SHARED_LIBS changes the versions of the produced file, i.e. make sure that ports is in control. Ok, now I have questions :). I was under the impression that the the SHARED_LIBS should match the .so name? This would be the case with 1.0, as upstream used 0.0 during development when there was no stable ABI/API (and users could have installed such a pre-1.0 release manually on OpenBSD). I could find https://man.openbsd.org/library-specs.7 which seems to indicate it must match the .so name, as well as lining out rules on when and how to update the version, which match upstream in this case (I can vouch for this, as I am the upstream). Given that, wouldn't it be better to have it 1.0 instead of always one major version less than upstream?* * Very, very early, there was a major version of as high as 8. But this was a decade or so ago and I think nobody ever used it. And on a version that was very much declared "this WILL break, don't use this for anything" -- Jonathan
Re: New port: devel/objfw
On 2023/08/30 18:34, A Tammy wrote: > > On 8/30/23 13:55, Jonathan Schleifer wrote: > > Hi! > > > > With ObjFW 1.0 being released yesterday, I thought to package it up > > for OpenBSD. Please find it attached and if it looks good, it would be > > great if it could be imported. > > > > Exciting! Thanks for the port. Built cleanly and all tests passed. > > Upstream doc says > > > It supports all modern Objective-C features when using Clang, but is > also compatible with GCC ≥ 4.6 to allow maximum portability. > > Unfortunate, our ports gcc doesn't support objcetive-c :( > > > SHARED_LIBS += objfw 1.0 > > SHARED_LIBS += objfwrt 1.0 > > SHARED_LIBS += objfwtls 1.0 > > I can't remember how strict we are with these version starting numbers > but iirc we start with 0.1 (?) I don't really mind if this isn't changed. > The bumpings are the more important ones anyway. 0.0. The key thing is to make sure that changing the versions in SHARED_LIBS changes the versions of the produced file, i.e. make sure that ports is in control.
Re: New port: devel/objfw
On 8/30/23 13:55, Jonathan Schleifer wrote: > Hi! > > With ObjFW 1.0 being released yesterday, I thought to package it up > for OpenBSD. Please find it attached and if it looks good, it would be > great if it could be imported. > Exciting! Thanks for the port. Built cleanly and all tests passed. Upstream doc says > It supports all modern Objective-C features when using Clang, but is also compatible with GCC ≥ 4.6 to allow maximum portability. Unfortunate, our ports gcc doesn't support objcetive-c :( > SHARED_LIBS += objfw 1.0 > SHARED_LIBS += objfwrt 1.0 > SHARED_LIBS += objfwtls 1.0 I can't remember how strict we are with these version starting numbers but iirc we start with 0.1 (?) I don't really mind if this isn't changed. The bumpings are the more important ones anyway. OK aisha@ to import. Cheers, Aisha
New port: devel/objfw
Hi! With ObjFW 1.0 being released yesterday, I thought to package it up for OpenBSD. Please find it attached and if it looks good, it would be great if it could be imported. -- Jonathan objfw.tar.gz Description: application/gzip
