From: Felipe Contreras <hidden> Date: 2021-05-12 23:21:27
This patch series is an attempt to cleanup a bit the Makefile regarding asciidoc stuff.
It does not enable asciidoctor direct manpage creation, that's in a separate patch.
Felipe Contreras (8):
doc: standardize asciidoc calls
doc: add an asciidoc helper
doc: disable asciidoc-helper for asciidoctor
doc: simplify the handling of interruptions
doc: remove redundant rm
doc: refactor common dependencies
doc: improve asciidoc dependencies
doc: join xml and man rules
Documentation/Makefile | 45 +++++++++++++-------------------
Documentation/asciidoc-helper.sh | 17 ++++++++++++
2 files changed, 35 insertions(+), 27 deletions(-)
create mode 100755 Documentation/asciidoc-helper.sh
--
2.31.1
From: Felipe Contreras <hidden> Date: 2021-05-12 23:22:01
asciidoctor handles interruptions correctly, no need for the helper.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/Makefile | 1 +
1 file changed, 1 insertion(+)
From: Felipe Contreras <hidden> Date: 2021-05-12 23:22:10
The hacks to deal with interrupted builds is scattered throughout the
Makefile, but not everywhere (it's not done for techical/ and articles).
It originally comes from f9dae0d3e6 (Documentation/Makefile: fix
interrupted builds of user-manual.xml, 2010-04-21), however, that
description is not correct.
asciidoc does actually remove the output file in case of an exception,
but there was a bug that handled keyboard interruptions through a
different path, and thus in that particular case the file is not
removed[1].
We shouldn't overly complicate the Makefile due to bugs in asciidoc.
In order to keep the Makefile clean this commit creates an asciidoc
wrapper that does the job of tracking the intermediary output.
Once asciidoc is fixed this helper can be safely removed and there would
be minimal changes elsewhere.
It's written for bash, but could easily be modified for something more
portable.
[1] https://github.com/asciidoc-py/asciidoc-py/pull/195
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/Makefile | 27 +++++++++------------------
Documentation/asciidoc-helper.sh | 18 ++++++++++++++++++
2 files changed, 27 insertions(+), 18 deletions(-)
create mode 100755 Documentation/asciidoc-helper.sh
@@ -0,0 +1,18 @@+#!/bin/bash++# This helper is a workaround for an interruption bug in asciidoc:+# https://github.com/asciidoc-py/asciidoc-py/pull/195++args=()++while[$#-gt1];do+case$1in+-o)shift;out="$1";;+*)args+=("$1")+esac+shift+done++rm-f"$out+""$out"&&+"${args[@]}"-o"$out+""$1"&&+mv"$out+""$out"
The hacks to deal with interrupted builds is scattered throughout the
Makefile, but not everywhere (it's not done for techical/ and articles).
It originally comes from f9dae0d3e6 (Documentation/Makefile: fix
interrupted builds of user-manual.xml, 2010-04-21), however, that
description is not correct.
asciidoc does actually remove the output file in case of an exception,
but there was a bug that handled keyboard interruptions through a
different path, and thus in that particular case the file is not
removed[1].
We shouldn't overly complicate the Makefile due to bugs in asciidoc.
In order to keep the Makefile clean this commit creates an asciidoc
wrapper that does the job of tracking the intermediary output.
Once asciidoc is fixed this helper can be safely removed and there would
be minimal changes elsewhere.
It's written for bash, but could easily be modified for something more
portable.
Both this and your first patch could just be made to use the
.DELETE_ON_ERROR flag instead, although that's a bigger change.
I had this and a related series for that recently:
https://lore.kernel.org/git/patch-4.6-2ff6359c273-20210329T161723Z-avarab@gmail.com/
I don't think anyone had an objection to using that, I didn't pursue it
because I was trying to make (among other things) AIX development less
annoying, but Junio didn't like the -o $@+ && mv $@+ $@ pattern for
object files, so I gave up on pursuing it.
But if you're trying to address this "maybe it errors" issue then
.DELETE_ON_ERROR is a better solution.
I think if we use that we should also undo your changes to use "-o file"
and instead pipe to the file ourselves, otherwise we'll probably have
cases where the program that fails and GNU make will race to delete the
file (but I haven't tested that case).
From: Felipe Contreras <hidden> Date: 2021-05-13 19:33:23
Ævar Arnfjörð Bjarmason wrote:
On Wed, May 12 2021, Felipe Contreras wrote:
quoted
The hacks to deal with interrupted builds is scattered throughout the
Makefile, but not everywhere (it's not done for techical/ and articles).
It originally comes from f9dae0d3e6 (Documentation/Makefile: fix
interrupted builds of user-manual.xml, 2010-04-21), however, that
description is not correct.
asciidoc does actually remove the output file in case of an exception,
but there was a bug that handled keyboard interruptions through a
different path, and thus in that particular case the file is not
removed[1].
We shouldn't overly complicate the Makefile due to bugs in asciidoc.
In order to keep the Makefile clean this commit creates an asciidoc
wrapper that does the job of tracking the intermediary output.
Once asciidoc is fixed this helper can be safely removed and there would
be minimal changes elsewhere.
It's written for bash, but could easily be modified for something more
portable.
It may be a bigger change on the general Makefile, but I don't think
that's the case for the documentation Makefile.
I don't think anyone had an objection to using that, I didn't pursue it
because I was trying to make (among other things) AIX development less
annoying, but Junio didn't like the -o $@+ && mv $@+ $@ pattern for
object files, so I gave up on pursuing it.
I really don't see what's the point of scattering all those rm mv all
over the place. If the command is interrupted (ctrl+C), then make will
remove the file anyway (regardless of .DELETE_ON_ERROR).
It's only a problem if the command fails for some other reason, in which
case the command itself should remove the file, or it's trapping the
SIGINT signal incorrectly (as is the case with asciidoc).
But if you're trying to address this "maybe it errors" issue then
.DELETE_ON_ERROR is a better solution.
Indeed, it seems so. Thanks.
I think if we use that we should also undo your changes to use "-o file"
and instead pipe to the file ourselves, otherwise we'll probably have
cases where the program that fails and GNU make will race to delete the
file (but I haven't tested that case).
Yes, although I would prefer to investigate what happens in that case,
and I bet no race happens (doing `rm -f` twice is not an issue).
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2021-05-12 23:22:46
By always specifying the output file it will be possible to refactor all
the calls in a future helper.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Felipe Contreras <hidden> Date: 2021-05-12 23:27:53
There's no need to have an intermediary file.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/asciidoc-helper.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
It would be so nice if this worked, but here is what I saw in a
quick-and-dirty experiment:
$ f () { echo foo >"$1" && sleep 20 && echo bar >>"$1"; }
$ f hoi ;# wait sufficiently long
$ cat hoi
foo
bar
$ f hoi ;# wait a bit and hit ^C
^C
$ cat hoi
foo
$ rm hoi
$ f hoi || rm hoi ;# wait a bit and hit ^C
^C
$ cat hoi
foo
So, I suspect it unfortunately may not work well.
We need to get 2/8 redone without bash-ism, but it would not affect
the correctness of this step, I would think, whether this is done in
bash or implemented in a plain vanilla POSIX shell.
Thanks.
It would be so nice if this worked, but here is what I saw in a
quick-and-dirty experiment:
$ f hoi || rm hoi ;# wait a bit and hit ^C
So, I suspect it unfortunately may not work well.
That's because the interrupt signal is not caught.
This works:
sh -c 'echo foo >"$1" && trap "exit 1" INT && sleep 20' test hoi || rm hoi
And so does this:
#!/bin/sh
ruby - hoi <<EOF || rm hoi
File.write(ARGV[0], 'foo')
begin
sleep(10)
rescue Exception
exit(1)
end
EOF
Both asciidoc and asciidoctor trap the signal.
We need to get 2/8 redone without bash-ism,
Yes, if we agree this approach is indeed desirable I can do that.
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2021-05-12 23:27:55
It's not clear what it was supposed to achieve.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
It seems this used to make sense around 7b8a74f39cb (Documentation:
Replace @@GIT_VERSION@@ in documentation, 2007-03-25), but at some point
(I didn't look further) we refactored that and kept the "rm".
From: Felipe Contreras <hidden> Date: 2021-05-13 18:58:45
Ævar Arnfjörð Bjarmason wrote:
On Wed, May 12 2021, Felipe Contreras wrote:
quoted
It's not clear what it was supposed to achieve.
It seems this used to make sense around 7b8a74f39cb (Documentation:
Replace @@GIT_VERSION@@ in documentation, 2007-03-25), but at some point
(I didn't look further) we refactored that and kept the "rm".
Actually it came later: 50cff52f1a (When generating manpages, delete
outdated targets first., 2007-08-02).
I'm not sure we should complicate the Makefile just because somebody
made the mistake of doing 'sudo make doc' a long time. Especially since
other rules don't have this.
sudo make doc
touch GIT-ASCIIDOCFLAGS
make doc
Fails here already.
asciidoc: FAILED: api-merge.txt: line 2: unexpected error:
asciidoc: ------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 6247, in asciidoc
writer.open(outfile, reader.bom)
File "/usr/bin/asciidoc", line 4633, in open
self.f = open(fname, 'w+', encoding='utf-8', newline="")
PermissionError: [Errno 13] Permission denied: '.../Documentation/technical/api-merge.html'
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2021-05-12 23:27:55
Will be useful later with asciidoctor that can do both at the same time.
Signed-off-by: Felipe Contreras <redacted>
---
Documentation/Makefile | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
It does mean that if manpage-base-url.xsl changes, we'll regenerate all
the xml files. Before this change, we would just rerun the xmlto step.
Also, this will break `make info`. It will either find xml files that
"happen" to be there, e.g., because you just built the manpages (or
maybe you did so several weeks ago), or it won't find them and error
out.
(If you're wondering if anyone is actually using `make info`, there's
some discussion at [1]. I don't think anyone would be too sad to see it
go. Once `make info` is the only reason we need to generate the xml
files, I think it's a given we should try to drop that stuff.)
I think we should keep the separate xml targets as long as "asciidoctor
without xmlto" isn't the only way we support building the manpages. If
the only benefit here is "later", I think we should do this patch later.
I could also imagine that the xml target will just go away once all the
"old" ways of building the manpages are gone and `make info` is gone,
i.e., when we simply don't need any of these generated xml files.
[1] https://lore.kernel.org/git/20200402004533.GA6369@camp.crustytoothpaste.net/
Martin
It does mean that if manpage-base-url.xsl changes, we'll regenerate all
the xml files. Before this change, we would just rerun the xmlto step.
True.
Also, this will break `make info`.
Ahh, I didn't see that dependency on MAN_XML.
(If you're wondering if anyone is actually using `make info`, there's
some discussion at [1]. I don't think anyone would be too sad to see it
go. Once `make info` is the only reason we need to generate the xml
files, I think it's a given we should try to drop that stuff.)
Perhaps, but not in this patch series.
I think we should keep the separate xml targets as long as "asciidoctor
without xmlto" isn't the only way we support building the manpages. If
the only benefit here is "later", I think we should do this patch later.
I could also imagine that the xml target will just go away once all the
"old" ways of building the manpages are gone and `make info` is gone,
i.e., when we simply don't need any of these generated xml files.
Agreed. I will drop this in the next version.
Cheers.
--
Felipe Contreras
Thanks. I was a bit lazy in a15ef383e7 ("Documentation/Makefile: add
missing dependency on asciidoctor-extensions", 2019-02-27).
We end up with some duplication. We could pull GIT-ASCIIDOCFLAGS into
some ASCIIDOC_DEPS_COMMON. But with just one such common dependency, it
seems unnecessary and overly complicated. We can pull out the common
dependencies when we actually gain something from it.
Martin