On Mon, May 19, 2014 at 8:36 AM, Lev Serebryakov <l...@serebryakov.spb.ru> 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/mspgcc-users@lists.sourceforge.net/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 Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
