>>> "Tom" == Tom Howard <[EMAIL PROTECTED]> 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