submitting a new port

submitting a new port

[Jaka Močnik]

hello!

we would like to submit a port of binutils to the NEC SX vector CPU
architecture for inclusion in the binutils CVS. apart from standard
stuff (as, ld, binutils), the port also introduces a new COFF flavour as
used on Super-UX on NEC SX machines.

the port (based on binutils 2.18) is fairly complete and working (tested
while porting gcc as well as with native SX compiler). I'm currently in
the process of merging it to latest binutils CVS HEAD and taking care of
"unbreaking" other COFF targets.

I have a few questions about merge of the port in mainline binutils:
- when would be an appropriate time to merge the port (not to interfere
with binutils release cycle)?
- how do I go about submitting? one patch or multiple
(per-functionality, per-component)? what about generated files that are
included in CVS (configures, Makefile.ins etc.) - should patches include
those or will someone else regenerate them?
- other things that need taking care of, but I don't know about them ...

and finally, a bit unrelated, as I would like to make a tarball of my
2.18 port - how do I do an equivalent of "make dist" in binutils?

thanks!

regards,
  jaKa

-- 
email: jaka@xlab.si
w3:    http://www.gmajna.net/svojat/jaka/

Re: submitting a new port

[Nick Clifton]

Hi Jaka,

> I have a few questions about merge of the port in mainline binutils:
> - when would be an appropriate time to merge the port (not to interfere
> with binutils release cycle)?

Now is a good time.  We are about to make the 2.19 release of binutils, 
but that will be happening from a branch, so commits to the mainline 
will not affect it.

> - how do I go about submitting? one patch or multiple
> (per-functionality, per-component)? 

One patch per sub-directory from the top level please.  (Ie one patch 
for bfd, one for gas, one for ld, etc).  It also helps if you have 
separate patches for the various testsuites, although this is not essential.

> what about generated files that are
> included in CVS (configures, Makefile.ins etc.) - should patches include
> those or will someone else regenerate them?

Someone else will regenerate them, so they should not be included in the 
patch submissions.  (This helps to make the submissions smaller). 
Please mention the regenerated files in the ChangeLog entries that 
accompany the patch submissions.

> - other things that need taking care of, but I don't know about them ...

Please consider adding entries to gas/NEWS and ld/NEWS mentioning the 
support for a new target.

Please consider adding testcases to the linker and assembler testsuites 
to check the behaviour of any features specific to your new target.

Please add documentation to the gas/doc/ directory describing the new 
target.


> and finally, a bit unrelated, as I would like to make a tarball of my
> 2.18 port - how do I do an equivalent of "make dist" in binutils?

When you say "make a tarball" do you mean a tarball of the sources ?  If 
so you can just do that by hand, eg "tar cfv binutils-2.18.tar *.  If 
you have been building in the source directories then you might like to 
run a distclean first.  eg:

   % cd <binutils-source-dir>
   % make distclean
   % cd ..
   % tar cvf - <binutils-source-dir> | lzma -9 binutils-2.18.tar.lzma


Cheers
   Nick



want to make a tarball of the built binaries