This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Now GCC is really hosed...
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: Now GCC is really hosed...
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Thu, 13 Jul 2000 17:53:35 -0400
- Cc: bkorb at sco dot COM, pfeifer at dbai dot tuwien dot ac dot at, gcc at gcc dot gnu dot org, mark at codesourcery dot com, rth at cygnus dot com
- References: <200007132116.RAA26430@caip.rutgers.edu>
On Thu, Jul 13, 2000 at 05:16:06PM -0400, Kaveh R. Ghazi wrote:
> > From: Bruce Korb <bkorb@sco.COM>
> >
> > Gerald Pfeifer wrote:
> > > Removing files generated by such tools from CVS will strictly reduce the
> > > ability of folks like Kaveh or myself to continually test GCC on not-so-
> > > common platforms (as we are often using guest accounts with limited disk
> > > space to do so, for example).
> >
> > Ah, here is the point where I have to be clearer than clear. :-)
> > Mark Mitchell removed files from CVS. I am proposing to RE-install
> > them, only to install them in a different place. Further, all the
> > non-platform specific generated files would be so moved.
> > At configure time, it would be determined whether or not the
> > tools exist to regenerate these files. If so, then at build
> > time the CVS generated files would be ignored and these files
> > would be regenerated during build. If not, then the Makefiles
> > would be told to use a script to fetch the files out of the
> > CVS gen tree. Nobody is saying you would have to have my
> > wierdo AutoGen thingey to build GCC from CVS. Though I am saying
> > that the CVS server would have to have that tool.
>
> I'm glad we won't be required to have these tools everywhere. Gerald
> is right, it would substantially reduce my ability to test various
> platforms.
>
> Q: If you are going to reinstall the generated files, why introduce
> the extra Makefile hair to sometimes create them and sometimes copy?
> Why not just always copy them from the gen dir?
I would imagine it is so that those people who are modifing the files during
implementation will have the right thing done (ie, invoke bison when the .y
file is changed), instead of always getting the old version from gen directory.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482