Integration into mainline is a goal, but the issue there is legal not
technical. Too many past authors are out of contact and may not have
provided release forms. Luca Bruno has offered to help address this at the
appropriate time.
However, please do look at the git repositories hosted on the mspgcc
project:
http://mspgcc.git.sourceforge.net/git/gitweb-index.cgi
The maint branch in each one includes a detailed description of the
branching policies. While the practices described may seem complicated, I
believe they meet the "simple as possible, but no simpler" requirement.
The code itself has been updated to improve the chance of upstream
integration (e.g., the gcc code was reformatted to meet the GNU coding
standard). The repositories are periodically synchronized with the upstream
development repositories, and the msp430 patches are current with upstream
development. I was pleased to find that gcc 4.5.2 produces code roughly 10%
smaller than gcc 4.4.5 with no other action required; gcc 4.6.0 will shave
off a couple more percent.
Please note that though I've made the "legacy" branches and even a
repository holding patch files available, I want the first official
re-release under mspgcc will be of the uniarch variant, which almost
certainly will break object-file compatibility with mspgcc4 (which is the
origin of the legacy variant). To avoid confusion, any packaging based on
these branches/patches should be clearly marked as "legacy". (I'm still
doing various squash/rebase operations on the uniarch code in the process of
cleaning it up so have not pushed it to a public repository where I won't be
able to do that anymore.)
I will try to document the plan for future development today, perhaps
placing it on the mspgcc wiki if I can create an appropriate page there.
Peter
On Mon, Feb 14, 2011 at 1:05 AM, Albert ARIBAUD <[email protected]>wrote:
> Le 14/02/2011 02:20, M. Andree a écrit :
> > Am 13.02.2011 23:29, schrieb Peter Bigot:
> >> There isn't really an overview of how it's done. I don't know how the
> >> previous maintainers did it; I have git repositories for binutils, gcc,
> and
> >> gdb, where I maintain branches that have all the patches applied, and
> use
> >> them to generate the patches that are added to the mspgcc4 distribution.
> I
> >> have not made those repositories available, except for binutils, because
> >> they're a mess and I don't want to support them.
> >
> > Neither do I know how Ivan did it, he valued code over documentation.
> >
> > Just from what I see, I suppose there was one pristine and one
> > mspgcc-enabled source tree, he hacked the latter into shape, then diffed.
> >
> > We've rewritten the build scripts more than once, too, but that's the
> > less interesting part.
> >
> >> A slightly more evolved version of the same scheme is done with the git
> >> repositories that are now available on the mspgcc project, which are
> about
> >> to supersede mspgcc4. For those I will not be providing packaging
> scripts
> >> like mspgcc4, which as you note are very inconvenient for people to
> modify.
> >> My hope is that this will convince people to take on the responsibility
> to
> >> build distributions for known platforms. (Also, I don't intend to make
> >> changes to support insight, though somebody else is welcome to take that
> >> on. The current version of gdb will be supported.)
> >
> > As far as I understand the issue, Insight ships with its own allegedly
> > modified copy of the Tcl/Tk/itcl/itk sources, and these don't build on
> > Cygwin 1.7, and as I've just learned from the thread, not on 64-bit
> > distros either. This has bit-rotten for over a year now; and I wonder
> > if Insight can be ported to work with stock versions of recent Tcl/Tk +
> > i* stuff.
>
> Peter, Andre,
>
> I assume that one long-term goal is to get the git repos into good
> enough a shape to hope for mainline submission, isn't it?
>
> I don't have much time on my hands, but if I have enough to pester you
> with bugfix requests (thanks, btw, for 3168920!) I guess I can spare
> some to look at the git repos and try to help shape them up.
>
> Amicalement,
> --
> Albert.
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
