Kaz Kylheku wrote:
> By the way, if parallelism is not desired, mention this special target
> somewhere in the Makefile:
>
> .NOTPARALLEL:
>
> Then -j is ignored.
Thanks; I knew that already from the documentation [1]. But I try to avoid
it, since other targets in the same Makefile may well profit from parallel
execution.
> > target: $(DEPS1)
> > $(MAKE) target2
>
> Whether equivalent or not, resorting to a re-execution of make
> is ugly. We'd like to avoid it.
That's precisely why I try to understand each of the drawbacks.
If I use $(MAKE), even without $(MAKEFLAGS), there is no problem with
make command-line options like '-n', right?
> If there is an order among the DEPS1 and DEPS2 dependencies,
> you have to express it to Make!
>
> Here is a small Makefile:
>
> DEPS1 := d1a d1b d1c
> DEPS2 := d2a d2b d2c
>
> all: $(DEPS1) $(DEPS2)
> @echo making $@ from $(DEPS1) and $(DEPS2)
>
> %:
> @echo making $@
>
> # Uncomment!
> # $(DEPS1): $(DEPS2)
Unfortunately, for the developer's convenience, stamp files are used
to avoid execution of costly rules when one of the dependencies has changed.
For example:
- The PDF formatted documentation is not rebuilt by "make", only by
"make pdf", when one of the input .texi files changes.
- The HTML formatted manual page of a program is not rebuilt (because
'help2man' followed by 'groff -html' is costly) when a .c file, from
which the program is built, has changed. One assumes that most changes
to a program will not have an effect on its '--help' output.
- The PO files and .mo files of a packages are not updated by "make",
because the maintainer would feel that this happens too often.
When stamp files are involved, you can't just add dependency lines like
$(DEPS1): $(DEPS2)
By the way, I would love to see a section about stamp files in the GNU make
manual. It's such a tricky topic :)
Bruno
[1] https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
