public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Per Bothner <bothner@cygnus.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: egcs@cygnus.com
Subject: Re: Can we remove bison output from cvs?
Date: Sun, 31 Jan 1999 23:58:00 -0000	[thread overview]
Message-ID: <199901132020.MAA22063@cygnus.com> (raw)
In-Reply-To: <199901131959.OAA17822@caip.rutgers.edu>

> Looking back at http://www.cygnus.com/ml/egcs/1999-Jan/0299.html you
> only propose doing it, you never state how it would improve things. 

Because the cvs archive should contain *source* files.
Files that can be generated should in principle not be there.
We may make some exceptions when it makes things easier,
but the general philosophy is that cvs should not contain
generated files.

Another lesser reason:  It would slightly simplify my life.
The current setup is inconsistent with how Cygnus maintains our
internal cvs tree.  Thus I need to do different things when
checking things into the internal tree and the Cygnus tree,
increasing the likelyhood of mistakes.  Since a large chunk
of Gcc work is done by Cygnus engineers, this is not just
for me.

> I remove snapshot builds daily.

But nobody is proposing removing the generated files from the
snapshots, only from the cvs archive!  If you want to test
the "instanteous" snapshots from the cvs archive, I think
it would make a lot of sense to have a main machine with cvs,
check it out, build a snapshot tarball from that (using
whatever script Jeff uses), and copy that tarball around
to your various machines.

Note:  Thus means we should also release a script that
produces a snapshot from the cvs source tree.  This should
ideally be a "dist" rule in the Makefile, for compatibility
with automake.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

  reply	other threads:[~1999-01-31 23:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-31 23:58 Kaveh R. Ghazi
1999-01-31 23:58 ` Per Bothner [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-01-31 23:58 Jan Reimers
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 Jan Reimers
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58   ` Bruce Korb
1999-01-31 23:58 Mike Stump
1999-01-31 23:58 Kaveh R. Ghazi
1999-01-31 23:58 ` Per Bothner
1999-01-31 23:58   ` Gerald Pfeifer
1999-01-31 23:58     ` Marc Lehmann
1999-01-31 23:58     ` Bruce Korb
1999-01-31 23:58       ` Joern Rennecke
1999-01-31 23:58         ` Bruce Korb
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 Per Bothner
1999-01-31 23:58 ` Joe Buck
1999-01-31 23:58   ` Jeffrey A Law
1999-01-31 23:58     ` Per Bothner
1999-01-31 23:58   ` David Starner
1999-01-31 23:58     ` Joe Buck
1999-01-31 23:58       ` Marc Espie
1999-01-31 23:58       ` Jeffrey A Law
1999-01-31 23:58 ` Bill Currie
1999-01-31 23:58   ` Jeffrey A Law
1999-01-31 23:58 Kaveh R. Ghazi
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 N8TM

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199901132020.MAA22063@cygnus.com \
    --to=bothner@cygnus.com \
    --cc=egcs@cygnus.com \
    --cc=ghazi@caip.rutgers.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).