Re: [NEW] textproc/scdoc
On 2020/01/24 00:19, Ingo Schwarze wrote: > Hi, > > Stuart Henderson wrote on Thu, Jan 23, 2020 at 11:26:12AM +: > > On 2020/01/22 23:34, Raymond E. Pasco wrote: > > >> Having looked at it a bit more, I see other statically linked ports with > >> empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's > >> correct. Since I don't know, here's another tgz identical to the last > >> but with WANTLIB=c (which, if you remove -static, is what it would > >> require). > > > Please don't statically link it. The few ports doing this are special cases. > > OK, here we go, with the following changes to what Raymond sent: > > * Delete -static from LDFLAGS in the Makefile. >I found no way to feed that in via the environment, >so i patched the Makefile. > > * Polish the COMMENT. Saying just "generator" is not helpful >because it doesn't say from which source format, and this is >particularly relevant here because it uses an extremely unusual >format that nothing else uses, so the claim "generator" is overly >broad. Also make it clear that generating man pages actually >means generating old 1979-style man(7) code. > > * Polish DESCR in the same vein. POSIX is irrelevant here; >were are writing a decsription for OpenBSD. > > > Obviously, this is only yet another low-quality man(7) generator > (emitting pointless low-level roff(7) code, lots of bogus .P, > incorrectly encoded dashes, using low-level font escapes rather > than proper man(7) macros, failing to properly generate .MT > and .UR, ... - and that's just from inspecting the thirty line > file scdoc.1 itself) so using it certainly isn't encouraged. > > But given that some people use it anyway for documentating their > software, i agree that a port is needed, even if only as a dependency > for other, potentially more useful ports. > > OK? > Ingo Add this, and it's OK sthen: MAKE_FLAGS =CC="${CC}"
Re: [NEW] textproc/scdoc
I would bet most people interested in this are interested in the aerc mail program (https://aerc-mail.org). (I am.)
Re: [NEW] textproc/scdoc
Thanks for the assistance.
Re: [NEW] textproc/scdoc
Hi, Jan Stary wrote on Fri, Jan 24, 2020 at 01:34:54PM +0100: > On Jan 24 00:19:40, schwa...@usta.de wrote: >> Obviously, this is only yet another low-quality man(7) generator >> (emitting pointless low-level roff(7) code, lots of bogus .P, >> incorrectly encoded dashes, using low-level font escapes rather >> than proper man(7) macros, failing to properly generate .MT >> and .UR, ... - and that's just from inspecting the thirty line >> file scdoc.1 itself) so using it certainly isn't encouraged. >> >> But given that some people use it anyway for documentating their >> software, i agree that a port is needed, even if only as a dependency >> for other, potentially more useful ports. > What ports are those? https://github.com/jasperla/openbsd-wip/tree/master/mail/aerc was already mentioned earlier in this thread. I admit there may not be many others, which isn't necessarily a bad thing given the above observations. Yours, Ingo
Re: [NEW] textproc/scdoc
On Jan 24 00:19:40, schwa...@usta.de wrote: > Obviously, this is only yet another low-quality man(7) generator > (emitting pointless low-level roff(7) code, lots of bogus .P, > incorrectly encoded dashes, using low-level font escapes rather > than proper man(7) macros, failing to properly generate .MT > and .UR, ... - and that's just from inspecting the thirty line > file scdoc.1 itself) so using it certainly isn't encouraged. > > But given that some people use it anyway for documentating their > software, i agree that a port is needed, even if only as a dependency > for other, potentially more useful ports. What ports are those? (I would grep for the dependency, but that does not exist yet.) Jan
Re: [NEW] textproc/scdoc
Hi, Stuart Henderson wrote on Thu, Jan 23, 2020 at 11:26:12AM +: > On 2020/01/22 23:34, Raymond E. Pasco wrote: >> Having looked at it a bit more, I see other statically linked ports with >> empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's >> correct. Since I don't know, here's another tgz identical to the last >> but with WANTLIB=c (which, if you remove -static, is what it would >> require). > Please don't statically link it. The few ports doing this are special cases. OK, here we go, with the following changes to what Raymond sent: * Delete -static from LDFLAGS in the Makefile. I found no way to feed that in via the environment, so i patched the Makefile. * Polish the COMMENT. Saying just "generator" is not helpful because it doesn't say from which source format, and this is particularly relevant here because it uses an extremely unusual format that nothing else uses, so the claim "generator" is overly broad. Also make it clear that generating man pages actually means generating old 1979-style man(7) code. * Polish DESCR in the same vein. POSIX is irrelevant here; were are writing a decsription for OpenBSD. Obviously, this is only yet another low-quality man(7) generator (emitting pointless low-level roff(7) code, lots of bogus .P, incorrectly encoded dashes, using low-level font escapes rather than proper man(7) macros, failing to properly generate .MT and .UR, ... - and that's just from inspecting the thirty line file scdoc.1 itself) so using it certainly isn't encouraged. But given that some people use it anyway for documentating their software, i agree that a port is needed, even if only as a dependency for other, potentially more useful ports. OK? Ingo tmp.tgz Description: application/tar-gz
Re: [NEW] textproc/scdoc
On 2020/01/22 23:34, Raymond E. Pasco wrote: > Having looked at it a bit more, I see other statically linked ports with > empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's > correct. Since I don't know, here's another tgz identical to the last > but with WANTLIB=c (which, if you remove -static, is what it would > require). Please don't statically link it. The few ports doing this are special cases.
Re: [NEW] textproc/scdoc
Having looked at it a bit more, I see other statically linked ports with empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's correct. Since I don't know, here's another tgz identical to the last but with WANTLIB=c (which, if you remove -static, is what it would require). scdoc-wantlib.tgz Description: GNU Zip compressed data
Re: [NEW] textproc/scdoc
> I _think_ it needs WANTLIB, bit I am not 100% sure on that. Once that's > sorted, OK abieber@ for import! I'm not sure when a port would or wouldn't WANTLIB=c, but lib-depends-check thinks it's superfluous here. > Side-note: If you are looking to import aerc, I have a wip of that as > well: aerc would be nice (I'm trying it out at the moment). Wasn't able to figure out how to make ports fetch go dependencies. I changed the target to pre-test as trondd suggested, which I think is correct. (I already submitted it upstream, anyway.) Attached. scdoc.tgz Description: GNU Zip compressed data
Re: [NEW] textproc/scdoc
On Sun, 19 Jan 2020 at 23:35:18 -0500, Raymond E. Pasco wrote: > This is a simple man page generation language. > > The only patch is to some tests, which failed because of errors in > the tests themselves rather than program errors. > > I'm not experienced at OpenBSD ports; feedback is appreciated. This is pretty similar to what I have in wip: https://github.com/jasperla/openbsd-wip/blob/master/textproc/scdoc/Makefile I _think_ it needs WANTLIB, bit I am not 100% sure on that. Once that's sorted, OK abieber@ for import! Side-note: If you are looking to import aerc, I have a wip of that as well: https://github.com/jasperla/openbsd-wip/tree/master/mail/aerc (might have some pointers :D) -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: [NEW] textproc/scdoc
On Sun, January 19, 2020 11:35 pm, Raymond E. Pasco wrote: > This is a simple man page generation language. > > The only patch is to some tests, which failed because of errors in > the tests themselves rather than program errors. > > I'm not experienced at OpenBSD ports; feedback is appreciated. > I gave it a test. I was thinking about porting this as a dependency of aerc. I would change the deletion of the test patch backup to just before running tests. Deleting it right after applying patches doesn't leave it around for debugging patch issues. pre-test: rm ${WRKSRC}/test/*.orig Otherwise, seems to check out. I'm not a commiter, though. :)
[NEW] textproc/scdoc
This is a simple man page generation language. The only patch is to some tests, which failed because of errors in the tests themselves rather than program errors. I'm not experienced at OpenBSD ports; feedback is appreciated. scdoc.tgz Description: GNU Zip compressed data