http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495
--- Comment #8 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2011-01-29
12:20:37 UTC ---
(In reply to comment #6)
> b) A .mod file is read when a USE statement is encountered; the file must
> exist
> and is searched for in the include search paths.
With any kind of module? Even special-case ones like iso_c_binding?
> c) If a MODULE is compiled again, but an existing .mod file would not change,
> the file modification date is not modified.
>
> d) Module files (.mod) contain the public procedure interfaces, type
> declarations and module variables of the module, including those made
> accessible via USE statements within the module
And are not compatible across major/minor/any compiler release/version?
> I think it would be useful to give an example Makefile file in the manual.
> Joost's solution (comment 2) seems to work fine, though I am not sure how
> protable to non-Unix platforms the "@true" is.
The @ specifier is portable make, 'true' is Posix but ':' is better as it is a
shell builtin command that does not fork. Pattern rules '%.foo: %.bar' however
are a GNU make feature not portable to Posix make, unlike inference rules
.bar.foo: which are portable but do not automatically chain (and have a couple
of other limitations).
Rules of the form
a b : c
commands ...
do *not* designate rules that update a and b at the same time. Rather, they
designate two distinct rules, one for a, and one for b, that happen to have the
same prerequisites and commands. If you want one rule to update multiple
outputs, see
<http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html>
(and no, that bit of the manual is *not* autotools-specific, so go somewhere
else with any flames please). Unfortunately that chapter still lacks info how
to cope well in the presence of 'make -n', this is only fixed in git Automake.
