| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
Pattern rules are cleaner, safer, and vouched for in the GNU make manual
itself. Supporting them instead of suffix rules will also allow us to
simplify a little the automake script, auxiliary perl modules, and
documentation.
This change introduces a slight backward-incompatibility now, in that
user provided definitions of the SUFFIXES variable or of the .SUFFIXES
target, as well as old-fashioned suffix rules, are now rejected.
Automake-NG still tries to parse and understand suffix-based pattern
rules though, to retain support for user-added file extensions in the
_SOURCES variables (see "Handling new file extensions" in the Automake
manual).
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
Note that suffix-based pattern rules with dot-less suffix are *not*
supported.
* NG-NEWS: Update.
* doc/automake.texi: Likewise.
* lib/am/footer.am: Declare '.SUFFIXES:' with empty dependencies, to
neutralize the default suffix rules.
* automake.in (&handle_footer): Reject the 'SUFFIXES' variable. Don't
process its content anymore. Don't generate the .SUFFIXES special target
anymore.
(&var_SUFFIXES_trigger): Remove. And don't install it as an hook for the
now-deprecated 'SUFFIXES' variable.
* lib/Automake/Rule.pm (&define): Don't process old-fashioned suffix
rules specially, but just reject them. Instead, process pattern rules
specially.
($_SUFFIX_RULE_PATTERN): Made local to the '&define' function, renaming
it as '$suffix_rule_rx'.
(&suffixes, @_suffixes): Delete, they are no more used.
(@EXPORT): Adjust.
(register_suffix_rule): Don't extend '@_suffixes' anymore.
(reset): Don't reset '@_suffixes' anymore.
* t/ext3.sh: Remove as obsolete.
* t/suffix4.sh: Likewise.
* t/suffix6.sh: Likewise.
* t/suffix6b.sh: Likewise.
* t/suffix7.sh: Likewise.
* t/suffix11.tap: Likewise.
* t/suffix6c.sh: Rename ...
* t/suffix-obj.sh: .. like this, and adjust.
* t/suffix-chain.tap: Rewrite a as "simple" test (rather than as
a TAP test), adjust, and rename ...
* t/suffix-chain.sh: ... like this.
* t/suffix3.tap: Likewise rewrite and rename ...
* t/suffix3.sh: ... like this.
* t/suffix8.tap: Likewise rewrite and rename ...
* t/suffix8.sh: ... like this.
* t/suffix10.tap: Likewise rewrite and rename ...
* t/suffix10.sh: ... like this.
* t/suffix5.sh: Adjust.
* t/suffix9.sh: Likewise.
* t/suffix13.sh: Likewise.
* t/parallel-tests8.sh: Likewise.
* t/warnings-strictness-interactions.sh: Likewise.
* t/warnings-win-over-strictness.sh: Likewise.
* t/warnings-precedence.sh: Likewise.
* t/warnings-override.sh: Likewise.
* t/warning-groups-win-over-strictness.sh: Likewise.
* t/amopts-variable-expansion.sh: Likewise.
* t/specflg10.sh: Likewise.
* t/suffix-rules-reject.sh: New test.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
