This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: Can we remove bison output from cvs?



  In message <199901102053.MAA09101@atrus.synopsys.com>you write:
  > 
  > > I would like to propose that we remove bison-generated .c and .h
  > > files from the cvs repository.  They would still be in the release
  > > and snapshot tar-balls, generated by whatever script makes those
  > > tar fils.
  > 
  > I second the motion, with the following caveat: we can remove a
  > derived file from CVS if and only if --
  > 
  > * we are relying on a standard FSF-released version of a tool (bison
  >   in this case) to build the derived file;
I believe that is the case for bison (and autoconf now that 2.13 has hit
the streets).


  > * we specify, at any time, which version of this tool is to be used
  >   to make the file (so that we are all testing the same code).
I seem to have bison-1.25 installed on my boxes.  I don't know if that is
the preferred version or not.

  > This would mean that we can't do the same for configure files until
  > we get a new autoconf release (since we are currently relying
  > on a snapshot here).
No longer true.  autoconf-2.13 has been released.

However, it may still be a bad idea to remove configure from the repo since
you need configure to build a Makefile.

  > Given this, it's a good thing, as small changes to the .y file
  > can generate large changes to parse.c (major changes to the tables),
  > and it's a waste of network bandwidth for everyone to suck down the
  > change.
Yup.  More importantly, it reduces the chance of someone forgetting to check
in the output file and folks getting inconsistent sources.

The other issue at hand is where are the parser files built?

Then can be built in the build directory.  That's how Cygnus does things, but
I don't want to force that convention on anyone.  The downside here is that
cvs folks and snapshot/release folks would be using different procedures since
the snapshots & releases need to continue to include the generated files. 


The other possibility is to build them into the source tree.  The downside here
is cvs update will start complaining about the parser files since they won't
be in the repository.

Jeff


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