>> I think I understand what's going on. The targets that call sub-makes >> look like: >>=20 >> ### Delivers: nut_version.h >> all-libs-local/include: >> +@NUT_VERSION_H_GENERATED=3Dfalse; export NUT_VERSION_H_GENERA= >TED; \ >> $(SUBDIR_TGT_RULE) >>=20 >> where >>=20 >> SUBDIR_TGT_RULE =3D ( \ >> ... \ >> $(MAKE) ... \ >> ... \ >> ) >>=20 >>=20 >> and this I think causes the "rule contains make" not to fire. > >Yes, exactly. To fire, the magic word "$(MAKE)" has to be directly in >the rule, and in this case, only the word "$(SUBDIR_TGT_RULE)" is >directly in the rule. > >> I wonder if -J is a concept in other BSD makes. > >In OpenBSD, parallel mode is implemented completely differently. For a >heuristic, it looks at the expanded command, not the unexpanded and thus >just works. FWIW in FreeBSD they set a flag to always pass the job queue and thus avoid this issue (one of the few remaining local FreeBSD changes). >> I wonder if you think not noticing the incorporated-by-reference $(MAKE) >> is a bug/misfeature? > >I didn't think about it as a bug yet, but now that you mention it, the >way OpenBSD does it makes more sense, it would free us from marking all >the recursive targets explicitly as ".MAKE" targets. True. In meta mode, if the target was not already deemed oodate by the normal rules, we may be looking at the expanded commands - to see if they changed, and it would make sense to check for 'make' while doing that, and marking the target .MAKE if approrpriate - which would avoid the need to re-examine the expanded commands just for that purpose. --sjg