Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

On Mon, May 19, 2014 at 8:36 AM, Lev Serebryakov <[email protected]> wrote:
> Hello, Peter.
> You wrote 19 мая 2014 г., 15:04:05:
>
> PB> A chain of messages related to building and packaging is available at:
> PB> http://www.mail-archive.com/[email protected]/msg12028.html
> PB> At least two of us have successfully built toolchains with those
> PB> instructions; how to convert them into packaging for a particular
> PB> distribution isn't something that's likely to come from this list.  My
> PB> recommendation is follow the distribution's standard practices for
> PB> cross-compilation toolchains and look to existing solutions like AVR
> PB> and ARM for guidance.
>   Problem with this instructions starts from very beginning:
>
> binutils git://sourceware.org/git/binutils-gdb.git master
> gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
> newlib git://sourceware.org/git/newlib.git master
>
>  Not-released software could not be packaged! We could only refer to stable,
> non-changeable, tarballs on vendor's server, not to some "git revision" or
> some "${packaghename}.tar.bz2", which could be changed (re-rolled) under same
> name :(

This is a distribution policy.  Most distributions have a solution for
that problem, based on an archived canonical tarball.  Some, like
Yocto, even extend that to support packaging never-released versions
through reference to a git SHA1 or SVN commit in a public repository
branch that the maintainers promise to never rebase.

There are also release branches in those repositories which you could
try (gcc-4_9-branch is one of them).

>  It is not exactly "how to convert them into packaging for a particular distribution
> isn't something that's likely to come from this list.", it is discussion
> about status of toolchain which, as I could say now, is not ready for
> distro-packaging due to absence of any suitable "releases", may be,
> snapshot-quality, but "stable" in sense of content.

If you mean that strictly, I don't think it'll be true for
msp430-elf-gcc until all the component packages have stable releases
that are known to interoperate, and possibly never unless TI promises
not to "changed (re-rolled) under same name" the pieces that are only
available from them, and makes the material compatible with those
stable releases rather than just their fork.

You may be waiting a while.

> PB> Personally I would not package a vendor-supplied fork, but that's a
> PB> policy decision for the distribution.
>  Yep, but on other hand it is "stable", well-named file :)

Perhaps.  Certainly using that instead of the upstream versions is a
choice a distribution might make.

> PB> Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
> PB> supported will vanish.  Unofficially, that's already occurred.
>  Anyway, thank you for all you work on mspgcc!

You're welcome.

Peter

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users