This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Newbie: How to support new processor architecture


At 3:32 PM +0200 5/13/02, Stefan Heinzmann wrote:
>Hi all,
>
>I am currently in the process of adding support for a new processor
>architecture to binutils (Hyperstone E1 processors, coff format). As
>I'm not intimately familiar with the toolset, I've got a few questions
>and hope someone can help me with them:
>
>CVS setup:
>
>I am working with a cvs server here where I keep the sources. I
>imported an initial version of the sources (binutils, newlib,
>gdb+insight) which I checked out from anoncvs@sources.redhat.com. I
>keep all sources in a unified source tree (is that the right idea -- or
>is ist preferable to have a separate source tree for each
>distribution?).

	I use a unified tree also.

>  I want to commit my changes to my cvs server while
>tracking changes made on the main repository at redhat. From the cvs
>cederqvist manual I know that one possibility for doing this is to
>periodically get the newest sources from redhat and import them into my
>cvs repository, thereby creating a separate vendor branch which I can
>merge into my modified main trunk. That's ok so far, but I was
>wondering whether it is really necessary to get the entire source tree
>from redhat each time. It would be much better if I could just "update"
>my vendor branch from the cvs server at redhat, thereby saving
>bandwidth and server load on the redhat server. How would you do this,
>is there a recommended way?

	I have a normal CVS sandbox, that I use to checkout the 
latest copy of the source
	whenever I feel the need to update.

	I do an IMPORT from that source tree into my local CVS 
repository by cd-ing to
	the root of the sandbox, and issuing

		cvs -d /my/local/repository import .....

	CVS ignores CVS subdirectories, so that's just fine.

	The ONE thing this won't do is catch files that are DELETED from the
	public distribution (they'll still be live in my local 
repository.)  So, at very
	rare intervals (or when I think that may be breaking 
something :-), I do
	a tree diff asking for which files are in local and not in 
remote.... and manually do
	cvs remove's

	The only other funny behavior I see with this is occasional 
trouble with RCS keyword
	expansion.  I think that the "right" thing to do is to turn 
off keyword expansion
	completely in my local repository - it hasn't bitten me so far :-)


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation


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