5.4 Packaging Generated Files
The debate about what to do with generated files is one which is keenly
contested on the relevant Internet mailing lists. There are two points
of view and I will present both of them to you so that you can try to
decide what the best policy is for your project.
One argument is that generated files should not be included with a
package, but rather only the `preferred form' of the source code
should be included. By this definition, `configure' is a derived
file, just like an object file, and it should not be included in the
package. Thus, the user should use the GNU Autotools to bootstrap
themselves prior to building the package. I believe there is some merit
to this purist approach, as it discourages the practice of packaging
derived files.
The other argument is that the advantages of providing these files can
far outweigh the violation of good software engineering practice
mentioned above. By including the generated files, users have the
convenience of not needing to be concerned with keeping up to date with
all of the different versions of the tools in active use. This is
especially true for Autoconf, as `configure' scripts are often
generated by maintainers using locally modified versions of
autoconf and locally installed macros. If `configure'
were regenerated by the user, the result could be different to that
intended. Of course, this is poor practice, but it happens to reflect
reality.
I believe the answer is to include generated files in the package when
the package is going to be distributed to a wide user community (ie. the
general public). For in-house packages, the former argument might make
more sense, since the tools may also be held under version control.
|