Simple freestanding C99 library for Unicode string handling.
Details
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
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.
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.
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.
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)...
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.
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)