0

I'm porting a home-baked makefile setup into the autotools suite. I've run into a problem for which I haven't yet found a suitable answer. It may be that I'm just not using the correct terms in my searches. Being a complete neophyte to autotools, I probably just don't know enough of the jargon.

The problem: our build process has a dependency for a header file which is generated from a csv file. (I don't know why. It is what it is.) In our old system, we did something like this:

.PHONY: all
all : header.csv.h $(objects)

header.csv.h:
    python prebuild.py

# remainder for building objects and the file lib.a

Finding this link to extend default rules, I've added this to my Makefile.am

noninst_LIBRARIES = libstuff.a

# .. Additional CXXFLAGS and CPPFLAGS, and listing the sources

all-local: header.csv.h

header.csv.h:
    python prebuild.py

The remade Makefiles still didn't work. Inspection of the generated Makefile for this part of the library showed this:

# lots of stuff preceeding
all: all-am
all-am: Makefile $(LIBRARIES) all-local

all-local: header.csv.h
# the rest as above

Right there in all-am: is the problem. The $(LIBRARIES) dependencies are listed first and are therefore being built first. Some further reading on the extending link above shows this is to be expected: no way to guaranteeing the order. It's simple enough to "fix": move all-local to precede $(LIBRARIES). However, this only fixes it once. I must guarantee this is always built first.

Can I add things to the configure script to be executed during the configuration process? What's the right way to handle something like this?

Andrew Falanga
  • 2,274
  • 4
  • 26
  • 51
  • None of this actually is related to autotools... but I salute you for attempting the conversion. I'm not that brave. – Ben Voigt Feb 25 '15 at 00:58
  • possible duplicate of [Header dependency in automake](http://stackoverflow.com/questions/1779984/header-dependency-in-automake) – Ben Voigt Feb 25 '15 at 19:58

1 Answers1

1

You're not supposed to write rules which depend on the order things are listed in the Makefile. There's no reason to have this rule at all (I understand it's a direct translation of your old Makefile -- which was also wrong):

all-local: header.csv.h

because header.csv.h is not a build product that needs to appear at the end of the make process. Instead you need

somesourcefile.o : header.csv.h

reflecting the true fact, that building somesourcefile.o requires the header file to exist, because somesourcefile.cpp includes it. If it is included in multiple places, you might need multiple of these rules.

When you specify dependencies correctly, make will calculate the dependency graph, and build things in the correct order.

Also, this rule

header.csv.h:
    python prebuild.py

should almost certainly be

header.csv.h : header.csv prebuild.py
    python prebuild.py

to make sure it gets rebuilt when either the source data or the translation rules change, and not when they don't.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Thank you for the clear answer. I agree with this assessment. It seemed to make sense at the time. The question now is, how do I override the rule that will be auto-generated for this one target (I've verified, it is just one *.cpp file)? – Andrew Falanga Feb 25 '15 at 15:14
  • You don't override it, just use both rules. From the documentation: "Multiple Rules for One Target --- One file can be the target of several rules. All the dependencies mentioned in all the rules are merged into one list of dependencies for the target. If the target is older than any dependency from any rule, the commands are executed." – Ben Voigt Feb 25 '15 at 15:40
  • I am at a loss then for how to handle this. I found the rule that builds the *.o file needing this header. I put something like this in my *Makefile.am*: `dir/object.o: header.csv.h`. However, this **did** override the rule and this, from the extending site, "... So it is not possible to append new dependencies ... without redefining the entire rule." Am I using the wrong file? I thought this object file was the subject of your suggestion. – Andrew Falanga Feb 25 '15 at 19:37
  • @AndrewFalanga: Is the auto-generated rule a pattern? In that case it won't append. Or maybe automake is seeing your rule and not generating its own? Does it change if you put your rule in a separate file, and then include it from Makefile.am ? – Ben Voigt Feb 25 '15 at 19:54
  • @AndrewFalanga: Ahh, found the answer. And your question actually ends up being a duplicate. – Ben Voigt Feb 25 '15 at 19:58
  • Yeah, I can't imagine I was the first. As I alluded, as a neophyte, I probably don't know enough jargon to find the answer using Google (a powerful tool, but without the right words, it's useless). Nevertheless, I literally stumbled on [the answer](http://www.gnu.org/software/automake/manual/automake.html#Sources). This variable with my rule to make the header, works as I need it to. – Andrew Falanga Feb 25 '15 at 20:30
  • @AndrewFalanga: Yes, the [question and answer](http://stackoverflow.com/questions/1779984/header-dependency-in-automake) I linked yours to uses that variable `BUILT_SOURCES` and also describes limitations and workarounds for its odd behavior. – Ben Voigt Feb 25 '15 at 20:32