Re: Exploring the option to submit the CR16 compilersourcecodeto GNU

["Gali Carmel" <Gali dot Carmel at nsc dot com>]

Hi,

Thank you very much for the detailed information. I am looking forward for our cooperation.
We are looking at all the details and if anything is unclear I will get back to you.

Regards,
Gali




geoffk@geoffk.org on 05/01/2001 09:39:00 PM
To:	Gali Carmel/Americas/NSC@NSC
cc:	gcc@gcc.gnu.org@Internet 

Subject:	Re: Exploring the option to submit the CR16 compiler sourcecodeto GNU

"Gali Carmel" <Gali.Carmel@nsc.com> writes:

> --0__=C2256A3F0030A5228f9e8a93df938690918cC2256A3F0030A522
> Content-Type: text/plain; 
>  charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 
> Hi,
> 
> I am Gali Carmel from National Semiconductor.  National Semiconductor
> has a family of CPUs named CompactRISC and I am the manager of team that
> develops and supports the developement toolset for the CPUs from this
> family.  Our compiler is GNU based and we wish to submit its source code
> to the GNUs web site (as it's done with other GNU-based compilers).

Great!

Here's a checklist of things that will need to happen before the code
goes in:

1. The new port should be prepared as a patch to the current CVS source
   tree.  You can find descriptions of how to check out the tree and
   the proper format for such a patch on the GCC web site at
   <http://gcc.gnu.org>.

2. You need to submit the patch (in the proper format) to the GCC patches
   mailing list.  Be sure that:
   - The patch follows the GNU coding conventions (for source code layout)
   - The patch includes a ChangeLog entry
   - It's in diff -c or diff -u format
   - You've tested it, and it at least compiles (preferably, you've
     run the testsuite and you think the results are OK).
   - The new port can be one big patch including the new files in
     gcc/config/whatever and changes to the toplevel configure scripts to
     have them recognize the new port, but if the port requires
     changes to the generic parts of the compiler then these should be
     in separate patches, one for each new bit of functionality.

3. You need to assign the copyright to the FSF.  If the port is currently
   owned by NatSemi, the easiest thing is to have NatSemi assign it to
   the FSF, and there is a form for that.

4. There is someone who can maintain the port.  How this is done depends
   on the nature of the port; if you happen to have a simulator and
   a binutils port, then that makes it much easier as it's not necessary
   to have the right hardware to maintain it.  If hardware is necessary,
   it's probably best if someone at NatSemi can commit to being the
   maintainer.  The maintainer needs to be able to make changes, so
   they usually need to have a copyright assignment that assigns future
   changes (there's a form for that too).

5. The patch will be reviewed and hopefully approved (perhaps after a few
   rounds, especially if you miss one of the items in (2) above, but the
   requirements for new ports are not particularly strict).  Then
   the maintainer can commit it to the CVS archive and you are done.

-- 
- Geoffrey Keating <geoffk@geoffk.org>