github: actions: build in parallel

[tleb]

According to GitHub's documentation, actions have access to 4 CPUs. Exploit those.

Untested. I tried using the act project to run GitHub actions locally but got some errors. Let's see what this PR's actions say.

[tpetazzoni]

Why not about building in parallel, but your other commit to update Ubuntu will I believe no longer apply as we updated to Ubuntu 24.04. I don't think we want to use "latest" as this will change "magically" over time, making things not reproducible, and breaking without us actually wanting an update. Could you drop this commit from the PR (it's unrelated to the PR topic anyway)

[miquelraynal]

Hello @tleb, can you update this PR? Or is it no longer relevant and we can close it?

[tleb]

No it is still relevant, just that it is broken. The goal is to be able to do make -j$(nproc) for the GitHub actions. But before that, parallel compilation must be working and it isn't (see how all the tests failed).

I read a bit the Makefile this morning, and I think our main issue is with:

training-materials/Makefile

Lines 243 to 260 in 349470e

	#
	# === Compilation of agendas ===
	#
	ifdef AGENDA
	AGENDA_TEX = agenda/$(AGENDA)-agenda.tex
	AGENDA_PICTURES = $(COMMON_PICTURES) $(call PICTURES,agenda)
	%-agenda.pdf: common/agenda_old.sty common/agenda.sty $(AGENDA_TEX) $(AGENDA_PICTURES) $(OUTDIR)/last-update.tex
	rm -f $(OUTDIR)/$(basename $@).tex
	cp $(filter %-agenda.tex,$^) $(OUTDIR)/$(basename $@).tex
	(cd $(OUTDIR); $(PDFLATEX_ENV) $(PDFLATEX) $(basename $@).tex)
	(cd $(OUTDIR); $(PDFLATEX_ENV) $(PDFLATEX) $(basename $@).tex > /dev/null 2>&1)
	cat $(OUTDIR)/$@ > $@
	else
	FORCE:
	%-agenda.pdf: FORCE
	@$(MAKE) $@ AGENDA=$*
	endif

Notice how shared targets will be attempted in different make processes. How to fix? We should remove this sub-make process instantiation.

[miquelraynal]

Will the typst transition help in building the materials in parallel? Or maybe it is no longer needed given how faster this is now happening?

[tleb]

Most likely no. We still do the sub-make incantation: we have daddy-make spawning N baby-makes each trying to build one slides PDF. The issue is that to build slides they have shared dependencies so baby-makes will all attempt resolving their dependencies at the same time.

I say "most likely" because in theory it could work if all targets resist races and build their dependencies "atomically". It is unlikely, and even if it works, it would be wasted efforts.

We ought to switch to only one make process (ie no babies involved).