Page MenuHomeFreeBSD

textproc/libgrapheme: New port
ClosedPublic

Authored by kfv on Fri, Oct 16, 12:51 PM.
Tags
None
Referenced Files
F176292680: D60773.id190097.diff
Sat, Oct 17, 5:46 PM
F176248934: D60773.id190097.diff
Sat, Oct 17, 8:07 AM
F176247147: D60773.id190061.diff
Sat, Oct 17, 7:42 AM
F176246115: D60773.id190097.diff
Sat, Oct 17, 7:27 AM
F176245443: D60773.id190032.diff
Sat, Oct 17, 7:18 AM
F176228056: D60773.id.diff
Sat, Oct 17, 3:38 AM
F176216003: D60773.id190061.diff
Sat, Oct 17, 1:01 AM
F176211431: D60773.id190032.diff
Sat, Oct 17, 12:09 AM
Subscribers

Details

Summary

Simple freestanding C99 library for Unicode string handling.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kfv requested review of this revision.Fri, Oct 16, 12:51 PM
kfv created this revision.
textproc/libgrapheme/Makefile
27

Remove blank line at end (found by: portlint)

textproc/libgrapheme/pkg-descr
11

Remove blank line at end (found by: portlint)

It's strange that you have to pass in CC and so on in MAKE_ARGS. Conventionally they are passed in through MAKE_ENV and it works.

LGTM and approved for commit.

This revision is now accepted and ready to land.Fri, Oct 16, 6:42 PM

Remove unnecessary blank lines

This revision now requires review to proceed.Fri, Oct 16, 6:46 PM
kfv marked 2 inline comments as done.Fri, Oct 16, 6:47 PM
This revision is now accepted and ready to land.Fri, Oct 16, 8:25 PM

It's strange that you have to pass in CC and so on in MAKE_ARGS. Conventionally they are passed in through MAKE_ENV and it works.

That's true, it was just out of habit. I've been away from ports for quite a few years now, so apologies for the slip. I'll leave it as is for now but I'll keep this in mind going forward. I need to refresh my knowledge of the framework; I'll do shortly.

This revision was automatically updated to reflect the committed changes.

Can we please try to add unit test when possible to at least attempt to ensure that basic functionality works as intended?

Can we please try to add unit test when possible to at least attempt to ensure that basic functionality works as intended?

Sure, but in this case, I left it out deliberately as 3.0.0 ships Unicode 17.0.0 data, but its line-break code still implements the 15.1 rules, resulting in 744 of 19,338 line-break conformance tests failing; upstream’s make test masks this by returning 0. I’m trying to raise this upstream first, and I’ll update once things are either settled or clarified.

In D60773#1394388, @kfv wrote:

It's strange that you have to pass in CC and so on in MAKE_ARGS. Conventionally they are passed in through MAKE_ENV and it works.

That's true, it was just out of habit. I've been away from ports for quite a few years now, so apologies for the slip. I'll leave it as is for now but I'll keep this in mind going forward. I need to refresh my knowledge of the framework; I'll do shortly.

Please remove these variables if they aren't needed. Check make -VMAKE_ENV. If it's in there, you most likely don't have to pass it explicitly.
If you leave in the explicit assignment, this'll be very confusing to people wishing to make changes on your port, and it's best not to do stuff that is not needed.

Sure, but in this case, I left it out deliberately as 3.0.0 ships Unicode 17.0.0 data, but its line-break code still implements the 15.1 rules, resulting in 744 of 19,338 line-break conformance tests failing; upstream’s make test masks this by returning 0. I’m trying to raise this upstream first, and I’ll update once things are either settled or clarified.

Better hook up the test suite, but document that it currently does not pass. Yuri likes to do a thing where he writes don the number of cases expected to pass and fail so you can quickly see if there is cause for alarm.

Just mentioned it in the commit message, there's no need to clutter the Makefile with that information (which also tends to go stable because people forget)...

In D60773#1394406, @fuz wrote:
In D60773#1394388, @kfv wrote:

It's strange that you have to pass in CC and so on in MAKE_ARGS. Conventionally they are passed in through MAKE_ENV and it works.

That's true, it was just out of habit. I've been away from ports for quite a few years now, so apologies for the slip. I'll leave it as is for now but I'll keep this in mind going forward. I need to refresh my knowledge of the framework; I'll do shortly.

Please remove these variables if they aren't needed. Check make -VMAKE_ENV. If it's in there, you most likely don't have to pass it explicitly.
If you leave in the explicit assignment, this'll be very confusing to people wishing to make changes on your port, and it's best not to do stuff that is not needed.

I just took a look and it seems suckless ports have this practice in common; I presume it's because they set CC et al with plain = in config.mk, so make lets those assignments override whatever MAKE_ENV passes in (see x11/slock, x11/tabbed, x11-wm/dwm, and misc/sent). Say, with CC=gcc14 and CFLAGS+=-fanalyzer in make.conf, dropping CC="${CC}" makes build with base cc while still getting our CFLAGS, and staging would fail on unknown argument '-fanalyzer', right? If so, keeping it as-is would be preferred. I might be proper wrong, though, I'm just thinking out loud to find whether there's been a rationale in keeping it this way for such ports, so correct me please if anything.

Sure, but in this case, I left it out deliberately as 3.0.0 ships Unicode 17.0.0 data, but its line-break code still implements the 15.1 rules, resulting in 744 of 19,338 line-break conformance tests failing; upstream’s make test masks this by returning 0. I’m trying to raise this upstream first, and I’ll update once things are either settled or clarified.

Better hook up the test suite, but document that it currently does not pass. Yuri likes to do a thing where he writes don the number of cases expected to pass and fail so you can quickly see if there is cause for alarm.

Cool. OK then, I'll do a DR for it shortly.

In D60773#1394435, @kfv wrote:

Cool. OK then, I'll do a DR for it shortly.

Make sure to either mention this DR on the new, or double-back here to mention the new DR (either way, it will successfully cross-link the two for others -- present and future -- to follow along)

Make sure to either mention this DR on the new, or double-back here to mention the new DR (either way, it will successfully cross-link the two for others -- present and future -- to follow along)

Roger that.