Re: [PATCH v2 7/9] sparse: Fix errors due to missing target-specific variables

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 19, 2011, 18:18 UTC
Message-ID: <7vbp025clq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DADC729.5060705@ramsay1.demon.co.uk>

Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:

Show 5 quoted lines

> I decided not to mark the $(SP_OBJ) as .PHONY targets; after some
> testing, it seems that it is not necessary, even if users do
> something like:
>     make git.sp 2>git.sp
> Do you know of any advantages to doing so that I have missed?

The info documentation on GNU make states two reasons to use .PHONY.

One is to avoid existing file (e.g. git.sp in the above) to interfere (especially when the target itself does not have a listed dependency), and the other is that .PHONY tells make that it does not have to spend cycles to consider implicit rules.

> -help.o: common-cmds.h
> +help.sp help.o: common-cmds.h

I am not sure if you even want any dependency listed for any %.sp target to begin with. If sparse _were_ a normal build target, it would be sensible to change the rule for sparse to create/update %.sp files, perhaps even like this:

> +%.sp: %.c GIT-CFLAGS FORCE

	rm -f $@+ $@

> +	$(QUIET_SP)cgcc -no-compile $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) \
> +		$(SPARSE_FLAGS) $< 2>&1 >$@+

	mv $@+ $@

so that once you run sparse on help.c, unless you touch help.c or do something to cause common-cmds.h to be updated, you do not have to run the same thing again whose outcome you have already seen.

BUT. That is obviously not what we want.

In the case of sparse, you *do* want it to be run every time the user says "make sparse", even when you already know you would get exactly the same result from the previous run.

The situation is exactly the same as "make clean"; it runs even when it is run immediately after another "make clean".

So why list any dependency? If it is sensible to treat "sparse" target just like "clean" target, it would make sense not to give it any dependencies and mark it as .PHONY, no?