This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: OT: How do people set up long term development
>>> I am wondering how people outside of Red Hat do long term
>>> development of compiler tools when you can't check the machine
>>> specific sources into the FSF repository until the NDA on the
>>> machine has been lifted?
This page:
http://arch.fifthvision.net/bin/view/Main/InteroperatingWithCVS
describes an approach in which you `cvs update' from the central
repository for merging in FSF sources, but use arch privately. arch
is _ideal_ for working on on two systems ("desktop, laptop") and nice
for other reasons as well.
I'm not sure I recommend this approach, quite yet, for GCC. The size
of the GCC tree is, I suspect, right around the edge of
"uncomfortable" for the current release of arch. Maybe not -- try it
out if you are so inclined -- but also be aware of the upcoming
quantum-leap in arch performance with the new C version (see
=READEME.new-stuff) in the distro.
(arch's "home" is http://regexps.srparish.net/www)
-t
> From: Michael Meissner <gcc-mail@the-meissners.org>
> On Wed, May 28, 2003 at 05:07:19PM +0200, Jakub Jelinek wrote:
>> On Wed, May 28, 2003 at 11:02:11AM -0400, Michael Meissner wrote:
>>> I am wondering how people outside of Red Hat do long term
>>> development of compiler tools when you can't check the machine
>>> specific sources into the FSF repository until the NDA on the
>>> machine has been lifted? The intention is that when the
>>> chipset I am developing the GNU toolchain for is formally
>>> announced, I will submit the files to the FSF for
>>> consideration of inclusion in the releases, and non-machine
>>> specific changes that I make will be contributed as they are
>>> written.
>>> I can see three different development models:
>>> 1) Create my own CVS repository of a checked out releases, and
>>> check the files into there. Every so often, I will do a merge
>>> from the FSF sources to my own repository. This is how we did
>>> development at OSF, Cygnus, and Red Hat. The problem is doing
>>> the merge step, and there isn't a direct correlation between
>>> the versions in the master repository and my system. If all
>>> of the tools had CVS tags for nightly snapshots, it would make
>>> things easier, but the bintuils directories don't seem to have
>>> snapshot tags. This is the way I'm leaning, since it will
>>> allow me to work on two systems (desk system, laptop) and
>>> using cvs to do the update.
>> cvs update -jgcc-3_3-branch:2003{0517,0528} works IMHO just
>> fine, you don't need any nightly tags for it. All you need is
>> to remember what was the last date you did a cvs merge at,
>> which can be recorded e.g. in the CVS commit messages.
> Thanks.
> Wouldn't it have problems if there was a commit that occured
> around midnight, particularly a multi-file commit, one file
> being committed before midnight, and the other after midnight.