Running make using multiple jobs fails

[vtraag]

When running make in order to build the source tarball igraph_[VERSION].tar.gz, it pre-compiles the YACC and LEX files. The rules that are used to compile it are not compatible with using multiple jobs (using -j). This is presumably due to the fact that building those files use the same temporary files:

rigraph/Makefile

Lines 45 to 52 in 5e7a689

	%.c: %.y
	$(YACC) $<
	mv -f y.tab.c $@
	mv -f y.tab.h $(@:.c=.h)
	%.c: %.l
	$(LEX) $<
	mv -f lex.yy.c $@

This does not seem to be a problem when building C igraph, which can be built using parallel jobs. The resulting automake build rule is somewhat different than what seems to be required here:

.l.c:
	$(AM_V_LEX)$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE)

.y.c:
	$(AM_V_YACC)$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h `echo $@ | $(am__yacc_c2h)` y.output $*.output -- $(YACCCOMPILE)

I'm not immediately sure how to translate this to the more simpler Makefile that is used to build the source tarball for R igraph. If the Makefile remains incompatible with parallel builds, we should at least make sure to document it somewhere.

[QuLogic]

In Make, $* is the stem, i.e., the part that matches % in the rule. This can be used to generate temporary file names that are specific to each input.

[vtraag]

The $(YLWRAP) script uses a temporary directory to copy the resulting y.tab.c and y.tab.h to the intended destination/name. Something similar should be done in this Makefile in order to support parallel builds.

[QuLogic]

I would not consider this actually fixed.

[vtraag]

I would not consider this actually fixed.

The original complaint was that it failed, it now no longer fails. Surely it can be made more efficient, but the make is only used when bootstrapping the build from the GitHub repository, and takes relatively little time. The compilation of the source code itself takes substantially more time, and parallel building is correctly supported there. So as far as I'm concerned we can consider this fixed.

Having said that, if you have an improvement over simply forcing a non-parallel build @QuLogic, that would of course be welcome!