This is the mail archive of the
mailing list for the GCC project.
Re: Exploring the option to submit the CR16 compilersourcecodeto GNU
- To: geoffk <geoffk at geoffk dot org>
- Subject: Re: Exploring the option to submit the CR16 compilersourcecodeto GNU
- From: "Gali Carmel" <Gali dot Carmel at nsc dot com>
- Date: 06 May 2001 23:19:37 -0700
- Alternate-Recipient: Allowed
- cc: "Gali Carmel" <Gali dot Carmel at nsc dot com>, gcc <gcc at gcc dot gnu dot org>
- Conversion: Allowed
- Disclose-Recipients: Prohibited
- Original-Encoded-Information-Types: IA5-Text
- X400-Content-Type: P2-1988 ( 22 )
- X400-MTS-Identifier: [/c=us/admd= /prmd=National/;0B7EE3AF63E79043-MTANSC1]
- X400-Originator: Gali.Carmel@nsc.com
- X400-Received: by mta MTANSC1 in /c=us/admd= /prmd=National/; Relayed;06 May 2001 23:19:37 -0700
- X400-Received: by /c=us/admd= /prmd=National/; Relayed; 06 May 2001 23:19:37 -0700
- X400-Recipients: non-disclosure;
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.
firstname.lastname@example.org on 05/01/2001 09:39:00 PM
To: Gali Carmel/Americas/NSC@NSC
Subject: Re: Exploring the option to submit the CR16 compiler sourcecodeto GNU
"Gali Carmel" <Gali.Carmel@nsc.com> writes:
> Content-Type: text/plain;
> Content-Transfer-Encoding: 7bit
> 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).
Here's a checklist of things that will need to happen before the code
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
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 <email@example.com>