So what I want is to add a build variant for a library built from the same source, but with different compiler options.

Following automake documentation, I have something like this (distilled from a much larger, auto-generates Makefile.am):

# Rules to build crtMCU.o and crtMCU-cvt.o from gcrt1.S

nodist_libcrt_a_SOURCES = gcrt1.S
nodist_libcvt_a_SOURCES =

noinst_LIBRARIES = libcrt.a libcvt.a
libcvt_a_LIBADD = gcrt1-cvt.o

avrdir = ...
avrlibdir = ...
avr_DATA = crtMCU.o

cvtdir = ...
cvtlibdir = ...
cvt_DATA = crtMCU-cvt.o

For crtMCU.o there is this rule that works:

crtMCU.o: gcrt1.o
    rm -f $@
    ln $< $@ || cp $< $@

For crtMCU-cvt.o according to the documentation, there is these rules:

gcrt1-cvt.o: gcrt1.S
    $(CPPASCOMPILE) -c -o $@ $< $(CVT_OPTIONS) ...

crtMCU-cvt.o: gcrt1-cvt.o
    rm -f $@
    ln $< $@ || cp $< $@

Now when building, then gcrt1.o gets compiled with -MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo where the .deps file lists all the dependencies.

But when building gcrt1-cvt.o, there is no such dependency file (which is understandable since the build rule is written by hand).

Question

What is the proposed way to add similar dependencies (they are the same) for build variant gcrt1-cvt.o?

Note: What I don't understand is for why the Makefile.am is building libraries (which are not used). The build goal is to build and install crtMCU.o and crtMCU-cvt.o. No *.a is needed.

So what I want is to add a build variant for a library built from the same source, but with different compiler options.

Following automake documentation, I have something like this (distilled from a much larger, auto-generates Makefile.am):

# Rules to build crtMCU.o and crtMCU-cvt.o from gcrt1.S

nodist_libcrt_a_SOURCES = gcrt1.S
nodist_libcvt_a_SOURCES =

noinst_LIBRARIES = libcrt.a libcvt.a
libcvt_a_LIBADD = gcrt1-cvt.o

avrdir = ...
avrlibdir = ...
avr_DATA = crtMCU.o

cvtdir = ...
cvtlibdir = ...
cvt_DATA = crtMCU-cvt.o

For crtMCU.o there is this rule that works:

crtMCU.o: gcrt1.o
    rm -f $@
    ln $< $@ || cp $< $@

For crtMCU-cvt.o according to the documentation, there is these rules:

gcrt1-cvt.o: gcrt1.S
    $(CPPASCOMPILE) -c -o $@ $< $(CVT_OPTIONS) ...

crtMCU-cvt.o: gcrt1-cvt.o
    rm -f $@
    ln $< $@ || cp $< $@

Now when building, then gcrt1.o gets compiled with -MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo where the .deps file lists all the dependencies.

But when building gcrt1-cvt.o, there is no such dependency file (which is understandable since the build rule is written by hand).

Question

What is the proposed way to add similar dependencies (they are the same) for build variant gcrt1-cvt.o?

Note: What I don't understand is for why the Makefile.am is building libraries (which are not used). The build goal is to build and install crtMCU.o and crtMCU-cvt.o. No *.a is needed.

• makefile
• dependencies
• autotools
• automake

• Where do the differing compiler options come in? I don't know any reason why such an objective should take you anywhere near the custom rules you present, or to the issue with dependencies that you've asked about. – John Bollinger Commented Feb 10 at 19:19
• And how does it make sense to install object files? And if that's what you actually want to do, then why do you start off saying you want a build variant for a library? Libraries and object files are different things. – John Bollinger Commented Feb 10 at 19:22
• The extra options are in the "..." part of $(COMPILE). That's what the automake docs is proposing -- at least if I understand it correctly. It's for a libc implementation for a µC, and it's shipping the startup code in *.o since the beginning of time 25 years ago. Dunno why that design decision was made back then, and I definetely don't want to change that to a proper library and making all hell break loose. E.g. the compiler is linking crt<mcu>.o and has no means to determine which version of libc is installed. And there are free floating support packs with *.o as well. – emacs drives me nuts Commented Feb 10 at 19:37
• "The extra options are in the "..." part of $(COMPILE)" -- no such thing is presented in the question, and that seems doubtful to me in practice. Note well that the page you've linked from the manual does not rely on $(COMPILE) to expand differently in the two custom rules. Note also the last part of that page, starting with "As it turns out, there is also a much easier way to do this same task." Is there a reason why you're trying to do this the hard way instead of the easy way? – John Bollinger Commented Feb 10 at 19:50
• Sorry for being unclear. I edited the question and added $(CVT_OPTIONS) for indication. – emacs drives me nuts Commented Feb 10 at 20:57

2 Answers 2

What should work is to add gcrt1.o as an additioal depencency:

gcrt1-cvt.o: gcrt1.S gcrt1.o
    $(COMPILE) -c -o $@ $< ...

Hence whenever the dependencies for gcrt1.o change and hence that module is rebuilt, then gcrt1-cvt.o will be rebuilt, too.

And better use $(CPPASCOMPILE) instead of $(COMPILE) for assembling an assembly file.

Note: What I don't understand is for why the Makefile.am is building libraries (which are not used). The build goal is to build and install crtMCU.o and crtMCU-cvt.o. No *.a is needed.

The libraries are presumably a vehicle to get the object files built. This is a slight abuse of Automake, but not horrendous.

Automake generates rules for object files only in service to the goal of building a program or library. In the Makefile.am fragment presented, libcvt.a and libcrt.a are designated among the noinst_LIBRARIES, which means that rules for building the libraries will be generated, and they will be in the prerequisite tree for all, but the standard installation rules will not install them to the system. Building these libraries involves building all the contributing sources, modulo analysis of which of the resulting object files are already up to date, and that's what gets your object file(s) built.

What is the proposed way to add similar dependencies (they are the same) for build variant gcrt1-cvt.o?

The easy way would be to work with Automake by naming gcrt1.S among the sources for libcvt.a, too:

nodist_libcrt_a_SOURCES = gcrt1.S
nodist_libcvt_a_SOURCES = gcrt1.S

Or, since those are bona fide make variables, you could consider:

nodist_libcrt_a_SOURCES = gcrt1.S
nodist_libcvt_a_SOURCES = $(nodist_libcrt_a_SOURCES)

The latter emphasizes that the two libraries intentionally have identical source lists, and it may be more convenient and easier to maintain in cases where the source lists are longer.

Either way, Automake will then generate rules to assemble gcrt1.S separately for each library, to a different object file, using the options defined for the intended library in each case. It will likewise generate the wanted dependency rules for both object files.

In conjunction with this, delete