bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

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 'address@hidden' address in CC:, so that this discussion
gets properly recorded in the automake bug tracker.  Thanks.