Re: "include $(top_builddir)/aminclude.am" is ignored by automake

[Alexandre Duret-Lutz]

>>> "Tom" == Tom Howard <address@hidden> writes:

[...]
 >>>> don't use include.  Instead try to use AC_SUBST_FILE, or (IMHO better)
 >>>> something like AC_CONFIG_FILES([Makefile:Makefile.in:fragment.mk]).
[...]
 Tom> automake complains that fragement.mk is not found.  I can just touch the
 Tom> file before running autoreconf, but is there a nice way to tell automake
 Tom> that it can ignore that this files is missing?

No.  If Automake requires a file, it's because it wants to
distribute it.  If fragment.mk is generated, it should not be
distributed (touching the file or adding rules will not prevent
this).

In 1.9.x, the only way Automake can recognize that the input
file of an AC_CONFIG_FILES is generated is if this input file is
also the output file of another AC_CONFIG_FILES.

In the future Automake 1.10 you should be able to hide arbitrary
inputs to Automake using shell variables, but this workaround
not work with 1.9.x.  (I'm appending the 1.10 documentation for
AC_CONFIG_FILES for reference.)

I guess that leaves you with AC_SUBST_FILE...  Or maybe explain
what is the actual problem you are trying to solve, in case
somebody has a solution?

----------------------------------------------------------------------

`AC_CONFIG_FILES'
`AC_OUTPUT'
     These two macros are usually invoked as follows near the end of
     `configure.ac'.

          ...
          AC_CONFIG_FILES([
            Makefile
            doc/Makefile
            src/Makefile
            src/lib/Makefile
            ...
          ])
          AC_OUTPUT

     Automake uses these to determine which files to create (*note
     Creating Output Files: (autoconf)Output.).  A listed file is
     considered to be an Automake generated `Makefile' if there exists
     a file with the same name and the `.am' extension appended.
     Typically, `AC_CONFIG_FILES([foo/Makefile])' will cause Automake to
     generate `foo/Makefile.in' if `foo/Makefile.am' exists.

     When using `AC_CONFIG_FILES' with multiple input files, as in
     `AC_CONFIG_FILES([Makefile:top.in:Makefile.in:bot.in])', Automake
     will generate the first `.in' input file for which a `.am' file
     exists.  If no such file exists the output file is not considered
     to be Automake generated.

     Files created by `AC_CONFIG_FILES', be they Automake `Makefile's
     or not, are all removed by `make distclean'.  Their inputs are
     automatically distributed, except for inputs that turn out the be
     outputs of prior `AC_CONFIG_FILES' commands.  Finally, rebuild
     rules are generated in the Automake `Makefile' existing in the
     subdirectory of the output file, if there is one, or in the
     top-level `Makefile' otherwise.

     The above machinery (cleaning, distributing, and rebuilding) works
     fine if the `AC_CONFIG_FILES' specifications contain only
     literals.  If part of the specification uses shell variables,
     `automake' will not be able to fulfil this setup, and you will
     have to complete the missing bits by hand.  For instance on
 
          file=input
          ...
          AC_CONFIG_FILES([output:$file],, [file=$file])
 
     `automake' will output rules to clean `output', and rebuild it.
     However the rebuild rule will not depend on `input', and this file
     will not be distributed either.  (You must add `EXTRA_DIST =
     input' to your `Makefile' if `input' is a source file.)
 
     Similarly
 
          file=output
          file2=out:in
          ...
          AC_CONFIG_FILES([$file:input],, [file=$file])
          AC_CONFIG_FILES([$file2],, [file2=$file2])

     will only cause `input' to be distributed.  No file will be
     cleaned automatically (add `DISTCLEANFILES = output out'
     yourself), and no rebuild rule will be output.

     Obviously `automake' cannot guess what value `$file' is going to
     hold later when `configure' is run, and it cannot use the shell
     variable `$file' in a `Makefile'.  However, if you make reference
     to `$file' as `${file}' (i.e., in a way that is compatible with
     `make''s syntax) and furthermore use `AC_SUBST' to ensure that
     `${file}' is meaningful in a `Makefile', then `automake' will be
     able to use `${file}' to generate all these rules.  For instance
     here is how the Automake package itself generates versioned
     scripts for its test suite:

          AC_SUBST([APIVERSION], ...)
          ...
          AC_CONFIG_FILES([tests/aclocal-${APIVERSION}:tests/aclocal.in],
                          [chmod +x tests/aclocal-${APIVERSION}],
                          [APIVERSION=$APIVERSION])
          AC_CONFIG_FILES([tests/automake-${APIVERSION}:tests/automake.in],
                          [chmod +x tests/automake-${APIVERSION}])

     Here cleaning, distributing, and rebuilding are done automatically,
     because `${APIVERSION}' is know at `make'-time.

     Note that you should not use shell variables to declare `Makefile'
     files for which `automake' must create `Makefile.in'.  Even
     `AC_SUBST' does not help here, because `automake' needs to know
     the filename at run-time in order to check whether `Makefile.am'
     exists.  (In the very hairy case that your setup requires such use
     of variables, you will have to tell Automake which `Makefile.in's
     to generate on the command-line.)

     To summarize:
        * Use literals for `Makefile's, and for other files whenever
          possible.

        * Use `$file' (or `${file}' without `AC_SUBST([file])') for
          files that `automake' should ignore.

        * Use `${file}' and `AC_SUBST([file])' for files that
          `automake' should not ignore.

-- 
Alexandre Duret-Lutz