This is the mail archive of the
mailing list for the GCC project.
Re: cvs server: conflicts found in gcc/c-parse.c
- To: "Robert J. Brown" <rj at eli dot elilabs dot com>
- Subject: Re: cvs server: conflicts found in gcc/c-parse.c
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 01 Mar 1998 17:04:49 -0700
- cc: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, egcs-bugs at cygnus dot com, Jason Merrill <jason at cygnus dot com>, "H. J. Lu" <hjl at lucon dot org>
- Reply-To: law at cygnus dot com
In message <199803012342.RAA07051@eli.elilabs.com>you write:
> Gerald> On the other hand I do believe that autoconf, for example,
> Gerald> is not that widely installed, so autoconf generated files
> Gerald> should remain in the repository, IMHO.
> I do not think that *ANY* generated files should be checked into CVS
> unless we actually intent to edit these files and forget that at one
> time they were generated.
Removing the configure files is somewhat problematical since the end
developer would have to know to go run autoconf in all the appropriate
directories before he could configure & build. Or we have to hack
the toplevel configure script to go run autoconf. And where does
it put the generated configure files?
* If they go into the local source tree, then cvs will issue
warnings when you update your sources because your sources
will have files not found in the repository.
* If in the object tree, then we've got some major hackery to
do to make the generated configure files work correctly since
they assume that they're being run from the source tree.
These aren't issues for things like parser generated files which
can easily live in the object tree.
For reference, Cygnus's repository does include the configure files,
but not the other generated files (like parser stuff). This has
generally worked out well for us. This is the direction I'd like
to see egcs go, but then again, I'm biased because that's the
kind of setup I've been working with for the last few years :-)