Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi,
unless i'm missing something, everything discussed in this thread
should be fixed now, with the commit appended below.
Ingo Schwarze wrote on Thu, Dec 20, 2018 at 07:35:22PM +0100:
> Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +:
[...]
>> Rebuilding whatis databases:
>> makewhatis: man7/cmake-properties.7: ERROR: No such file or directory
[...]
> 1. The line number is missing, even though it is relevant.
> 2. Mentioning the .so request would be useful.
> 3. Mentining the file that was not found would be useful.
> 4. Most importantly, makewhatis(8) is not supposed
> to print mandoc(1) errors in this manner.
[...]
> Bug number 6: duoplicate reporting, two messages about the same problem
> in the input file, both with incomplete information. Not sure i can fix
> that one, but i shall try.
Fixing all that required much smaller code changes than i expected,
but explaining why these small changes do the job needed a substantial
commit message...
Speak up if you still see issues!
Thanks,
Ingo
Log Message:
---
Move the full responsibility for reporting open(2) errors from
mparse_open() to the caller. That is better because only the caller
knows its preferred reporting method and format and only the caller
has access to all the data that should be included - like the column
number in .so processing or the current manpath in makewhatis(8).
Moving the mandoc_msg() call out is possible because the caller can
call strerror(3) just as easily as mparse_open() can.
Move mandoc_msg_setinfilename() closer to the parsing of the file
contents, to avoid problems *with* the file (like non-existence,
lack of permissions, etc.) getting misreported as problems *in*
the file.
Fix the column number reported for .so failure:
let it point to the beginning of the filename.
Taken together, this prevents makewhatis(8) from spewing confusing
messages about .so failures to stderr, a bug reported by
Raf Czlonka on ports@.
It also prevents mandoc(1) from issuing *two* messages for every
single .so failure.
Modified Files:
--
mandoc:
main.c
read.c
Revision Data
-
Index: main.c
===
RCS file: /home/cvs/mandoc/mandoc/main.c,v
retrieving revision 1.313
retrieving revision 1.314
diff -Lmain.c -Lmain.c -u -p -r1.313 -r1.314
--- main.c
+++ main.c
@@ -510,7 +510,6 @@ main(int argc, char *argv[])
} else
thisarg = *argv;
- mandoc_msg_setinfilename(thisarg);
fd = mparse_open(curp.mp, thisarg);
if (fd != -1) {
if (use_pager) {
@@ -523,11 +522,13 @@ main(int argc, char *argv[])
conf.output.tag : *argv;
}
+ mandoc_msg_setinfilename(thisarg);
if (resp == NULL || resp->form == FORM_SRC)
parse(, fd, thisarg);
else
passthrough(resp->file, fd,
conf.output.synopsisonly);
+ mandoc_msg_setinfilename(NULL);
if (ferror(stdout)) {
if (tag_files != NULL) {
@@ -545,8 +546,9 @@ main(int argc, char *argv[])
outdata_alloc();
terminal_sepline(curp.outdata);
}
- }
- mandoc_msg_setinfilename(NULL);
+ } else
+ mandoc_msg(MANDOCERR_FILE, 0, 0,
+ "%s", strerror(errno));
if (curp.wstop && mandoc_msg_getrc() != MANDOCLEVEL_OK)
break;
Index: read.c
===
RCS file: /home/cvs/mandoc/mandoc/read.c,v
retrieving revision 1.207
retrieving revision 1.208
diff -Lread.c -Lread.c -u -p -r1.207 -r1.208
--- read.c
+++ read.c
@@ -372,8 +372,9 @@ rerun:
mparse_readfd(curp, fd, ln.buf + of);
close(fd);
} else {
- mandoc_msg(MANDOCERR_SO_FAIL, curp->line,
- pos, ".so %s", ln.buf + of);
+ mandoc_msg(MANDOCERR_SO_FAIL,
+ curp->line, of, ".so %s: %s",
+ ln.buf + of, strerror(errno));
ln.sz = mandoc_asprintf(,
".sp\nSee the file %s.\n.sp",
ln.buf + of);
@@ -633,7 +634,6 @@ mparse_open(struct mparse *curp, const c
/* Neither worked, give up. */
- mandoc_msg(MANDOCERR_FILE, 0, 0, "%s", strerror(errno));
return -1;
}
Re: [devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi Raf, Raf Czlonka wrote on Thu, Dec 20, 2018 at 02:59:23PM +: > Recently, I've noticed an odd-looking output from weekly(8): > > Rebuilding whatis databases: > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory You are right, there are a number of bugs here. I feel tempted to call it a cloud of mosquitoes. Thanks for the analysis. 1. The line number is missing, even though it is relevant. 2. Mentioning the .so request would be useful. 3. Mentining the file that was not found would be useful. 4. Most importantly, makewhatis(8) is not supposed to print mandoc(1) errors in this manner. The MANDOCERR_FILE enum item gets special handling in the code in several ways, but the effects are less than pretty. I think i have to revisit how this error item is generated and handled. > "Strange", I thought, especially since > /usr/local/man/man7/cmake-properties.7 is "alive" and well: > > $ ls -l /usr/local/man/man7/cmake-properties.7 > -rw-r--r-- 1 root bin 202877 Dec 20 14:00 > /usr/local/man/man7/cmake-properties.7 In general, the file name at the beginning of a mandoc(1) message is the name of the *input* file in which the error occurred, not the name of a file which mandoc tried to use. Here is bug number 5: That wasn't clearly stated in the manual page below: https://man.openbsd.org/mandoc#DIAGNOSTICS That's the first thing i fixed following your report, see the commit below. > I've rebuilt the mandoc.db I guess you mean "with makewhatis -D"? > and got an output which was stranger still: > > makewhatis: man7/cmake-properties.7: ERROR: No such file or directory > /usr/local/man//man7/cmake-properties.7: Adding to database > > Huh!? Right, makewhatis is indexing the file even though the content of the file is buggy. But that's OK as far as it goes. > Time for 'mandoc -Tlint': Excellent idea. > $ mandoc -Tlint /usr/local/man/man7/cmake-properties.7 | head > mandoc: /usr/local/man/man7/cmake-properties.7:1131:2: WARNING: .so is > fragile, better use ln(1): so libraries. > mandoc: /usr/local/man/man7/cmake-properties.7: ERROR: No such file or > directory > mandoc: /usr/local/man/man7/cmake-properties.7:1131:15: ERROR: .so > request failed: .so libraries. > [...] Bug number 6: duoplicate reporting, two messages about the same problem in the input file, both with incomplete information. Not sure i can fix that one, but i shall try. > OK, let's see what on that line: > > $ sed -n 1131p /usr/local/man/man7/cmake-properties.7 > .so libraries. > > and including preceding line: > > Set the Android property that specifies directories to search for the > .so libraries. > > Right, so '.so' (unintentional pun) is treated as a macro here - No, not as a macro, as a roff(7) request - but that isn't what the author intended, either. > moving it to the line above, fixes the issue: > > Set the Android property that specifies directories to search for the > .so > libraries. > > Upstream uses reStructuredText but I hope this[0] does the trick. > > [0] https://gitlab.kitware.com/cmake/cmake/merge_requests/2756 That's not a fix but merely a workaround for a bug in reStructuredText. It is more important to report the bug to reStructuredText than to work around it in each and every project using reStructuredText. The reStructuredText program ought to emit Set the Android property that specifies directories to search for the \&.so libraries. for the input in question. > Anyway, thought this might be of interest. Indeed, thank you for reporting. Ingo Log Message: --- Explain what the fields in mandoc messages mean, rather than merely specifying the message syntax. Gap in documentation found while looking at a bug report from Raf Czlonka . Modified Files: -- mandoc: mandoc.1 Revision Data - Index: mandoc.1 === RCS file: /home/cvs/mandoc/mandoc/mandoc.1,v retrieving revision 1.232 retrieving revision 1.233 diff -Lmandoc.1 -Lmandoc.1 -u -p -r1.232 -r1.233 --- mandoc.1 +++ mandoc.1 @@ -714,13 +714,29 @@ Messages displayed by follow this format: .Bd -ragged -offset indent .Nm : -.Ar file : Ns Ar line : Ns Ar column : level : message : macro args +.Ar file : Ns Ar line : Ns Ar column : level : message : macro arguments .Pq Ar os .Ed .Pp -Line and column numbers start at 1. +The first three fields identify the +.Ar file +name, +.Ar line +number, and +.Ar column +number of the input file where the message was triggered. +The line and column numbers start at 1. Both are omitted for messages referring to an input file as a whole. -Macro names and arguments are omitted where meaningless. +All +.Ar level +and +.Ar message +strings are explained below. +The name of the +.Ar macro +triggering the message and its +.Ar arguments +are
[devel/cmake] errors caused by cmake-properties.7 during makewhatis
Hi all, Recently, I've noticed an odd-looking output from weekly(8): Rebuilding whatis databases: makewhatis: man7/cmake-properties.7: ERROR: No such file or directory "Strange", I thought, especially since /usr/local/man/man7/cmake-properties.7 is "alive" and well: $ ls -l /usr/local/man/man7/cmake-properties.7 -rw-r--r-- 1 root bin 202877 Dec 20 14:00 /usr/local/man/man7/cmake-properties.7 I've rebuilt the mandoc.db and got an output which was stranger still: makewhatis: man7/cmake-properties.7: ERROR: No such file or directory /usr/local/man//man7/cmake-properties.7: Adding to database Huh!? Time for 'mandoc -Tlint': $ mandoc -Tlint /usr/local/man/man7/cmake-properties.7 | head mandoc: /usr/local/man/man7/cmake-properties.7:1131:2: WARNING: .so is fragile, better use ln(1): so libraries. mandoc: /usr/local/man/man7/cmake-properties.7: ERROR: No such file or directory mandoc: /usr/local/man/man7/cmake-properties.7:1131:15: ERROR: .so request failed: .so libraries. [...] OK, let's see what on that line: $ sed -n 1131p /usr/local/man/man7/cmake-properties.7 .so libraries. and including preceding line: Set the Android property that specifies directories to search for the .so libraries. Right, so '.so' (unintentional pun) is treated as a macro here - moving it to the line above, fixes the issue: Set the Android property that specifies directories to search for the .so libraries. Upstream uses reStructuredText but I hope this[0] does the trick. [0] https://gitlab.kitware.com/cmake/cmake/merge_requests/2756 Anyway, thought this might be of interest. Cheers, Raf
