This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cvs issues with .info files...


On Sun, Jul 17, 2005 at 06:03:56PM +0000, Thorsten Glaser wrote:
> Daniel Jacobowitz dixit:
> 
> >You just broke snapshots and release tarballs - they'll no longer have
> >info files in them, since they get prepared with distclean.  The things
> >that need to work are:
> >
> > - Ship tarballs with info files.
> 
> Uh, why?
> 
> You could probably do that by a tarball-local target or something.
> Still, I think it's stupid.

You might want to take a look at the GNU coding standards someday, if
you want to work on GNU projects...

  Naturally, all the source files must be in the distribution. It is okay
  to include non-source files in the distribution, provided they are
  up-to-date and machine-independent, so that building the distribution
  normally will never modify them. We commonly include non-source files
  produced by Bison, lex, TeX, and makeinfo; this helps avoid unnecessary
  dependencies between our distributions, so that users can install
  whichever packages they want to install.

It's a service to users.

> As for binutils - "all" does not include "info" anyway.

No, but install does.

> >But have you read the comments in automake describing
> >the problems with building info files in the build directory?
> 
> No, I've only tried to figure out - by reading the source
> of (an installed) automake - how to get that damn thing right.
> Without knowing perl.

There's an entire essay on this topic in there.  This is the relevant
bit:

      # 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).

It may be we bite the bullet and take #1.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]