diff options
author | Stefano Lattarini <stefano.lattarini@gmail.com> | 2012-05-26 11:39:29 +0200 |
---|---|---|
committer | Stefano Lattarini <stefano.lattarini@gmail.com> | 2012-05-29 12:31:29 +0200 |
commit | 645bb2101df2040ebedb65341cc786704c56f194 (patch) | |
tree | efacab35ea3823a1cf2d3ba78c3e0472f0a2c1b0 /NG-NEWS | |
parent | 04ea4fed10ada232fcd75a16b46e67f214396bf4 (diff) | |
download | automake-645bb2101df2040ebedb65341cc786704c56f194.tar.gz |
[ng] suffix: drop Automake-time chaining of suffix rules
This change simplifies the Automake::Rule module a little, moves yet
more logic from Automake runtime to GNU make runtime (in the spirit of
Automake-NG), and gets us rid of some never-documented nor completely
specified Automake magics. OTOH, it also breaks some idioms that, while
only relevant for uncommon cases, have been working since the first
Automake releases. Still, it is easy to slightly modify those idioms to
have the use cases they were catering to correctly handled with the new
semantics (examples of this are given below); the only downside being the
need of a little more verbosity and explicitness on the user's part.
So, with the present change, automake starts using a much simpler and
dumber algorithm to determine how to build an object associated to a
source whose extension in not one of those it handles internally.
The new algorithm goes like this. For any file listed in a '_SOURCES'
variable whose suffix is not recognized internally by automake (in
contrast to known suffixes like '.c' or '.f90'), automake will obtain
the expected target object file by stripping the suffix from the source
file, and appending either '.$(OBJEXT)' or '.lo' to it (which one depends
on whether the object is built as part of a program, a static library, or
a libtool library). It will then be assumed (but not checked!) that the
user has defined a rule (either explicit or defined from a pattern rule)
which can turn that source file into this corresponding object file. For
example, on an input like:
bin_PROGRAMS = foo
foo_SOURCES = mu.ext1 fu.ext1 zu.ext1
automake will expect that the three objects 'mu.$(OBJEXT)', 'fu.$(OBJEXT)'
and 'zu.$(OBJEXT)' are to be used in the linking of the 'foo' program, and
that the user has provided proper recipes for all those objects to be
built at make time, as well as a link command for linking 'foo'. Here is
an example of how those declarations could look like:
%.$(OBJEXT): %.ext1
my-compiler -c -o $@ $<
# We need to compile mu with debugging enabled.
mu.$(OBJEXT): mu.ext1
my-compiler -DDEBUG=1 -c -o $@ $<
foo_LINK = $(CC) -o $@
In this particular case, the idiom above is basically the same one that
would be required in mainline automake (apart for the fact that, there,
old-fashioned suffix rules should be used instead of pattern rules). To
see what is truly changed with the new algorithm, we have to look at a
more indirect usage.
Mainline Automake follows the chain of user-defined pattern rules to
determine how to build the object file deriving from a source file with
a custom user extension; for example, upon reading:
%.cc: %.zoo:
$(preprocess) $< > $@
bin_PROGRAMS = foo
foo_SOURCES = bar.zoo
automake knew that it has to bring in the C++ support (compilation rules,
requirement for AC_PROG_CXX in configure.ac, etc), and use the C++ linker
to link the 'foo' executable.
But after the present change, automake *won't follow those implicit
chains of pattern rules* anymore; so that the idiom above will have to
be re-worked like follows to preserve its intent and behaviour:
%.cc: %.zoo:
$(preprocess) $< > $@
bin_PROGRAMS = foo
# The use of '.cc' is required to let Automake know to bring in
# stuff for the handling of C++ compilation, and to use the C++
# linker to build 'foo'.
nodist_foo_SOURCES = bar.cc
EXTRA_DIST = foo.zoo
Finally, we must note another, slightly annoying first consequence of
this change of semantics: one can't use anymore "header files" with
extensions unrecognized to Automake anymore; for example, an usage like
this:
# Won't work anymore: will cause errors at make runtime.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c bar.my-hdr
BUILT_SOURCES = bar.h
will cause the generated Makefile to die on "make all", with an error
like:
make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'. Stop.
while an usage like this:
# Won't work anymore: will cause errors at automake runtime.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c foo.my-hdr
BUILT_SOURCES = foo.h
will cause automake itself to die, reporting an error like:
object 'foo.$(OBJEXT)' created by 'foo.my-hdr' and 'foo.c'
We don't believe the above breakage is a real issue though, because
the use case can still be served by placing the "non standard" headers
in EXTRA_DIST rather than in a _SOURCES variable:
# This will work.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c
EXTRA_DIST = foo.my-hdr
BUILT_SOURCES = foo.h
A more detailed list of changes follow ...
* automake.in (register_language): Don't call 'register_suffix_rule'
on the source and object extensions of the registered languages.
(handle_single_transform): Implement the new simple algorithm described
in details above (plus an hack to continue supporting Vala-related
'.vapi' files in _SOURCES variables). Remove the only call ever to ...
(derive_suffix): ... this function, which has thus been removed.
* lib/Automake/Rule.pm
($_suffix_rules_default, $suffix_rules, register_suffix_rule): Remove.
(@EXPORT, reset): Adjust.
(define): Don't call 'register_suffix_rule' on the suffixes of target
and dependency when a pattern rule is seen.
* t/specflg10.sh: Move ...
* t/am-default-source-ext.sh: ... to this more proper name, and
adjusted.
* t/suffix12.sh: Renamed ...
* t/suffix-custom-subobj.sh: ... to this, and remove a botched heading
comment.
* t/suffix3.sh: Adjust.
* t/suffix5.sh: Likewise.
* t/suffix8.sh: Likewise.
* t/suffix10.sh: Likewise.
* t/suffix13.sh: Likewise.
* t/suffix-chain.sh: Likewise.
* t/suffix-hdr.sh: Likewise.
* t/suffix-custom.sh: New test.
* t/suffix-custom-link.sh: Likewise.
* t/suffix-custom-default-ext.sh: Likewise.
* t/yacc-lex-cxx-alone.sh: Likewise.
* NG-NEWS: Update.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Diffstat (limited to 'NG-NEWS')
-rw-r--r-- | NG-NEWS | 109 |
1 files changed, 89 insertions, 20 deletions
@@ -177,26 +177,6 @@ Pattern rules and suffix rules not supported anymore either; Automake-NG will error out if you try to define them. -* To retain support for user-defined file extensions in the '_SOURCES' - variables (see "Handling new file extensions" in the Automake manual), - Automake-NG still tries to parse and understand suffix-based pattern - rules. So, an usage like: - - SUFFIXES = .baz .c - .baz.c: - cp $< $@ - foo_SOURCES = foo.c bar.baz - DISTCLEANFILES = bar.c - - which was valid with mainline Automake, should be translated for - Automake-NG as: - - %.c: %.baz - cp $< $@ - bin_PROGRAMS = foo - foo_SOURCES = foo.c sub/bar.baz - DISTCLEANFILES = bar.c - Distribution ============ @@ -257,6 +237,95 @@ Obsolete Features Removed a long time. +Source Files with Unknown Extensions +==================================== + +* Automake-NG used a much simpler and dumber algorithm that mainline + Automake to determine how to build an object associated to a source + whose extension in not one of those handled internally by automake. + + The new algorithm goes like this. For any file listed in a '_SOURCES' + variable whose suffix is not recognized internally by automake (in + contrast to known suffixes like '.c' or '.f90'), automake will obtain + the expected target object file by stripping the suffix from the source + file, and appending either '.$(OBJEXT)' or '.lo' to it (which one depends + on whether the object is built as part of a program, a static library, or + a libtool library). It will then be assumed that the user has defined a + rule (either explicit or defined from a pattern rule) which can turn that + source file into this corresponding object file. For example, on an + input like: + + bin_PROGRAMS = foo + foo_SOURCES = mu.ext1 fu.ext1 zu.ext1 + + automake will expect that the three objects mu.$(OBJEXT), fu.$(OBJEXT) + and zu.$(OBJEXT) are to be used in the linking of the 'foo' program, and + that the user has provided proper recipes for all those objects to be + built at make time, as well as a link command for linking 'foo'. Here + is an example of how those declarations could look like: + + %.$(OBJEXT): %.ext1 + my-compiler -c -o $@ $< + foo_LINK = $(CC) -o $@ + + In this particular case, the idiom above is basically the same one that + would be required in mainline automake (apart for the fact that, there, + old-fashioned suffix rules should be used instead of pattern rules). To + see what is truly changed with the new algorithm, we have to look at a + more indirect usage. + + Mainline Automake follows the chain of user-defined pattern rules to + determine how to build the object file deriving from a source file with + a custom user extension; for example, upon reading: + + .zoo.cc: + $(preprocess) $< > $@ + bin_PROGRAMS = foo + foo_SOURCES = bar.zoo + + *mainline* Automake knows that it has to bring in the C++ support + (compilation rules, requirement for AC_PROG_CXX in configure.ac, etc), + and use the C++ linker to link the 'foo' executable. + + But Autommake-NG *won't follow those implicit chains of pattern rules* + anymore; so that the idiom above will have to be re-worked like follows + to preserve its intent and behaviour: + + %.cc: %.zoo: + $(preprocess) $< > $@ + bin_PROGRAMS = foo + # The use of '.cc' is required to let Automake know to bring in + # stuff for the handling of C++ compilation, and to use the C++ + # linker to build 'foo'. + nodist_foo_SOURCES = bar.cc + EXTRA_DIST = foo.zoo + + And there is another major consequence of this change of semantics: one + can't use anymore "header files" with extensions unrecognized to Automake + anymore; for example, an usage like this will cause errors at make + runtime: + + # Won't work anymore. + %.h: %.my-hdr + $(preprocess-header) $< >$@ + foo_SOURCES = foo.c bar.my-hdr + BUILT_SOURCES = bar.h + + errors that might look like: + + make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'. Stop. + + The simple workaround is to place the "non-standard" headers in EXTRA_DIST + rather than in a _SOURCES variable: + + # This will work. + %.h: %.my-hdr + $(preprocess-header) $< >$@ + foo_SOURCES = foo.c + EXTRA_DIST = foo.my-hdr + BUILT_SOURCES = foo.h + + Miscellaneous ============= |