1

I have some problem adding specific rules to an autotools project.

I have this small exemple project :

project/configure.ac :

AC_INIT([myprog], [0.1], [dev@corp.com])
AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AM_EXTRA_RECURSIVE_TARGETS([quality])
AC_PROG_CC
AC_SUBST([AM_CFLAGS])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

project/Makefile.am:

SUBDIRS = src

project/src/Makefile.am:

bin_PROGRAMS= myprog

myprog_SOURCES    = myprog.c

QUALITYDIR=$(builddir)/quality
QUALITY_FILE="$(QUALITYDIR)/quality.log"

quality-local: $(QUALITY_FILE)

$(QUALITY_FILE): myprog
    mkdir -p $(QUALITYDIR)
    valgrind ./myprog 2>&1 | tee $(QUALITY_FILE)

CLEANFILES =    $(QUALITY_FILE)

Each time I do :

$ make quality

the valgrind stuff is run, even if "myprog" has not been rebuilt. I expect it shall only be executed when myprog is younger than the quality.log file in build/src/quality .

What do I do wrong ?

user2174468
  • 229
  • 1
  • 6

1 Answers1

1

Digging into your generated project/src/Makefile you'll see something like:

.PHONY: CTAGS GTAGS TAGS all all-am check check-am clean \
        ... quality-am quality-local ...

A .PHONY target will always be remade, so yes valgrind will always be run (which I also observed).

EDIT:

Forget all that. After running make -d quality (after already having made the log) I noticed:

  Considering target file '"./quality/quality.log"'.
   File '"./quality/quality.log"' does not exist.

So simply changing:

QUALITY_FILE="$(QUALITYDIR)/quality.log"

to

QUALITY_FILE=$(QUALITYDIR)/quality.log

should make it behave as you expect. At least it did for me.

ldav1s
  • 15,885
  • 2
  • 53
  • 56
  • I don't think that explains it. Yes, .PHONY targets are always remade, but that does not force a rebuild of their up-to-date prerequisites (consider that the conventional "all" target is ordinarily .PHONY). The OP's valgrind command is part of the recipe for a regular target; it should run only if that rule's target is absent or out of date with respect to its prerequisites. – John Bollinger Oct 09 '17 at 04:35
  • @JohnBollinger after playing around some more, I discovered that you are correct. – ldav1s Oct 09 '17 at 13:41
  • Good catch on the second try, +1. I'll add that this sort of thing is an excellent reason to write DRY make rules, and in particular, to use the built-in variable `$@` within a rule's recipe to refer to that rule's target. – John Bollinger Oct 09 '17 at 14:30
  • Thanks ldav1s, it works ! I don't really understand what was the problem with the double-quote though, is is a bug of automake ? – user2174468 Oct 09 '17 at 20:12
  • 1
    This isn't an automake bug. See [this answer](https://stackoverflow.com/a/23332194/425738) for more information. – ldav1s Oct 09 '17 at 20:51
  • It isn't even directly related to Automake, @user2174468. It is standard behavior for `make`. – John Bollinger Oct 10 '17 at 17:23