On 04/02/2012 10:12 PM, Roumen Petrov wrote: > Hi Stefano, > > Stefano Lattarini wrote: >> [SNIP] >> It should still be possible, with the right hack (which is tested in the >> testsuite, and required by other packages anyway). The baseline is: if >> you don't want your '.info' files to be distributed, then it should be >> easily possible to have them built in the builddir; but if you want them >> distributed, they will be built in the srcdir. > Sound like if user would like to distribute binaries they must be in source > directory . > Why generated file, not required for build process, has to be places in > source tree. > This is explained in excruciating details in some code comments in the automake script (in the 'handle_texinfo_helper', more precisely). I'll just copy and paste them here:
# Until Automake 1.6.3, .info files were built in the # source tree. This was an obstacle to the support of # non-distributed .info files, and non-distributed .texi # files. # # * Non-distributed .texi files is important in some packages # where .texi files are built at make time, probably using # other binaries built in the package itself, maybe using # tools or information found on the build host. Because # these files are not distributed they are always rebuilt # at make time; they should therefore not lie in the source # directory. One plan was to support this using # nodist_info_TEXINFOS or something similar. (Doing this # requires some sanity checks. For instance Automake should # not allow: # dist_info_TEXINFOS = foo.texi # nodist_foo_TEXINFOS = included.texi # because a distributed file should never depend on a # non-distributed file.) # # * If .texi files are not distributed, then .info files should # not be distributed either. There are also cases where one # wants to distribute .texi files, but does not want to # distribute the .info files. For instance the Texinfo package # distributes the tool used to build these files; it would # be a waste of space to distribute them. It's not clear # which syntax we should use to indicate that .info files should # not be distributed. Akim Demaille suggested that eventually # we switch to a new syntax: # | Maybe we should take some inspiration from what's already # | done in the rest of Automake. Maybe there is too much # | syntactic sugar here, and you want # | nodist_INFO = bar.info # | dist_bar_info_SOURCES = bar.texi # | bar_texi_DEPENDENCIES = foo.texi # | with a bit of magic to have bar.info represent the whole # | bar*info set. That's a lot more verbose that the current # | situation, but it is not new, hence the user has less to # | learn. # | # | But there is still too much room for meaningless specs: # | nodist_INFO = bar.info # | dist_bar_info_SOURCES = bar.texi # | dist_PS = bar.ps something-written-by-hand.ps # | nodist_bar_ps_SOURCES = bar.texi # | bar_texi_DEPENDENCIES = foo.texi # | here bar.texi is dist_ in line 2, and nodist_ in 4. # # Back to the point, it should be clear that in order to support # non-distributed .info files, we need to build them in the # build tree, not in the source tree (non-distributed .texi # files are less of a problem, because we do not output build # rules for them). In Automake 1.7 .info build rules have been # largely cleaned up so that .info files get always build in the # build tree, even when distributed. The idea was that # (1) if during a VPATH build the .info file was found to be # absent or out-of-date (in the source tree or in the # build tree), Make would rebuild it in the build tree. # If an up-to-date source-tree of the .info file existed, # make would not rebuild it in the build tree. # (2) having two copies of .info files, one in the source tree # and one (newer) in the build tree is not a problem # because 'make dist' always pick files in the build tree # first. # However it turned out the be a bad idea for several reasons: # * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave # like GNU Make on point (1) above. These implementations # of Make would always rebuild .info files in the build # tree, even if such files were up to date in the source # tree. Consequently, it was impossible to perform a VPATH # build of a package containing Texinfo files using these # Make implementations. # (Refer to the Autoconf Manual, section "Limitation of # Make", paragraph "VPATH", item "target lookup", for # an account of the differences between these # implementations.) # * The GNU Coding Standards require these files to be built # in the source-tree (when they are distributed, that is). # * Keeping a fresher copy of distributed files in the # build tree can be annoying during development because # - if the files is kept under CVS, you really want it # to be updated in the source tree; # - it is confusing that 'make distclean' does not erase # all files in the build tree. # # Consequently, starting with Automake 1.8, .info files are # built in the source tree again. Because we still plan to # support non-distributed .info files at some point, we # have a single variable ($INSRC) that controls whether # the current .info file must be built in the source tree # or in the build tree. Actually this variable is switched # off for .info files that appear to be cleaned; this is # for backward compatibility with package such as Texinfo, # which do things like # info_TEXINFOS = texinfo.txi info-stnd.texi info.texi # DISTCLEANFILES = texinfo texinfo-* info*.info* # # Do not create info files for distribution. # dist-info: # in order not to distribute .info files. HTH. > What if author(s) would like to separate process of document creation from > binaries ? > >> The rationale to do so is >> to ensure that, in both cases, the developer's tree layout (as bootstrapped >> from a VCS checkout) will match the user's tree layout (as obtained from a >> distribution tarball). > > May be I miss what is rationale to keep read-only and build-ready source tree. > I don't understand what you mean here. Could you please rephrase your statement? Regards, Stefano P.S. Please keep the '11...@debbugs.gnu.org' address in CC:, so that this discussion gets properly recorded in the automake bug tracker. Thanks.
