Try to fix parallel docs builds with collision avoidance per a2x-shared files#1152
Try to fix parallel docs builds with collision avoidance per a2x-shared files#1152jimklimov wants to merge 12 commits intonetworkupstools:masterfrom
Conversation
…docs that can collide on a2x implem detail (repopulated file in work dir)
… build them one after another to avoid a2x collisions when processing same source in parallel
…finished building (successfully) so we know if any parallel branches overlap
…ace-prone doc formats builds
…ilding all types regardless of enablement by configure script; also add "make man" support
… conflict about a2x, and add collision-avoidance
…DANCE_END like in man/Makefile.am
…arallel manpage builds to avoid conflicts
…figurable (e.g. larger for many small manpage files vs few big html docs)
…VOIDANCE that should be both faster and safer ...but alas - it suffers for texts that include each other (not resolved in the copy), and for shifted paths made with "make dist(check)".
|
UPDATE: Seems related to earlier efforts and discussions at #505, #418. One of those suggests just adding a hint to Note: finding a safe way to add parallelism is better. Docs builds are the major time consumer in CI jobs and developer workflows at least (where ccache helps for most other sources). |
|
It seems current a2x and asciidoc (9.0.0rc2 on my test system) can both be coerced into using output directories and so (checking) to not-conflict. Will explore that and maybe post an alternative PR if it seems a fruitful approach. |
jimklimov
changed the title
|
Closed due to functional and better solution in #1154 |
1 participant
Despite all the best efforts regarding dependency definitions, parallel builds and/or distchecks of NUT tend to fail. One toxic chain of events was linked to documentation -- the
a2xprogram tends to write and otherwise manipulate same-named files in the current directory, so build threads conflict with each other. A number of different workarounds was applied to reduce the chance of such conflicts (at a cost to build speed in some cases), although it seems problematic to rule them out completely: seems there is no portable feature for variedmakeimplementations to force running some targets sequentially.