This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


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

Re: gdb-5.0/gdb/doc/Makefile.in patch -- is this patch really correct?


Eli Zaretskii wrote:
> 
> > Date: Fri, 30 Jun 2000 10:18:45 -0400
> > From: Chris Faylor <cgf@cygnus.com>
> > >
> > >Did you look in the source distribution on ftp.gnu.org, or somewhere
> > >else?  I just looked in the GDB 5.0 distribution as downloaded from
> > >the GNU site, and the Info files are there in gdb/doc directory.
> >
> > I looked in the directory that I've checked out via CVS.  AFAICT, there are
> > no *.info files there.
> 
> Hmm...  This isn't right, the CVS reporitory should IMHO reproduce the
> contents of the distribution tarball.
> 
> Andrew, Stan, can you comment on this?

Mark is right, the info files are customarily included with the
distribution, even though they're not checked into CVS.  The section
"Making Releases" in the coding standards recommends including
info files, bison output, etc, so as to "avoid unnecessary
dependencies between our distributions".

However, it's up to us as to what's in CVS.  For instance, we could
opt not to check in configure, just configure.in, and expect that
everybody has the right version of autoconf.  That seems too extreme
though, since you must have a working configure even to get a build
started, so you'd be hosed if you didn't have a correct autoconf
(I've actually been hit by this; the CVS checkout of the SDL library
requires you to have automake, which is not set up on my Mac OS X system;
so I've been working with one of its releases instead.)

Should the info file be in CVS?  Well, the manual doesn't change so
routinely that info file updates would be time-consuming, but by the
same token very few people are going to feel the need; if they even
look at the info pages, they will most likely look at the installed
ones.  So I think we'd need to see some sort of compelling problem
that would be solved by changing the current practice.

Stan

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