I would recommend making gmp and mpfr those individual packages.  With
uniarch, binutils, gcc, and gdb should become individual packages as well as
each will be a single standalone patch file against upstream distributions,
with little to no requirement to update them all at the same time.

Peter

On Tue, Mar 8, 2011 at 3:06 AM, Matthias Ringwald <matth...@ringwald.ch>wrote:

> Hi Mark
>
> cool. we might collaborate a bit then. I was maintaining the AVR toolchain
> in Fink for many years and even was granted commit rights, so I might beat
> you in time ;)
>
> I don't have experience with MacPorts (only checked if there was some neat
> trick to compile stuff once in a while), but I had a quick look at your
> ports file. You just got feedback already. I was going to mention that gmp &
> mpfr are built as part of the mspgcc4 build, although those could be
> individual packages on their own.
>
> Best
>  Matthias
>
>
> On 07.03.2011, at 17:25, Mark J. Blair wrote:
>
> >
> > On Mar 7, 2011, at 12:20 AM, Matthias Ringwald wrote:
> >> Please tell me what changes you will have done when it's working. I'd
> like to make a script, installer, and/or, Fink package for that, to save
> others this hassle (and try to ask someone at TI for permission).
> >
> >
> > I'm working on creating MacPorts releases of both mspgcc4 and mspdebug,
> including the necessary drivers for use with mspdebug. I submitted the
> mspgcc4 port last week, and I should be able to submit the mspdebug-related
> ports this week. These are the first MacPorts releases I've worked on, and I
> don't know how long it usually takes for new submissions to show up.
> >
> > I contacted TI about redistribution of the serial port driver, since both
> the source and binary releases are packaged with a click-through license. I
> was told that I can't redistribute the original source, but I can
> redistribute binaries that I create from it. Thus, my MacPorts package for
> the driver will install a binary blob that I've compiled under Xcode, along
> with the modified plist.
> >
> > I've already created the portfiles for mspdebug itself and for the
> codeless kernel extension that's needed for the RF2500, but I'll submit them
> after I complete the serial port driver port.
> >
> > This is the ticket for my mspgcc4 submission, in case anybody's curious:
> >
> > http://trac.macports.org/ticket/28611
> >
> >
> > --
> > Mark J. Blair, NF6X <n...@nf6x.net>
> > Web page: http://www.nf6x.net/
> > GnuPG public key available from my web page.
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > What You Don't Know About Data Connectivity CAN Hurt You
> > This paper provides an overview of data connectivity, details
> > its effect on application quality, and explores various alternative
> > solutions. http://p.sf.net/sfu/progress-d2d
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to