Hello, David.
You wrote 8 июля 2013 г., 19:19:37:
>> DB> In an ideal world, TI would maintain its own apt repository (and yum),
>> And FreeBSD packages for i386, amd64, arm, MIPS, PowerPC, and ia64? And
>> repository for NetBSD and OpenBSD and MacOS X too?
DB> TI should (in an ideal world) have repositories containing toolchain
DB> releases for their chips, in a form suitable for the most commonly used
DB> platforms - and in source code for use on other platforms. If a lot of
Ok, "in source code for use on other platform" is good message. Other
question, how usable this source code and what voo-doo magic is needed to
build them on host unsupported by vendor (TI in this case). I see different
amount of such voo-doo in my life: from "almost imposible" (egcs3 for MIPS
used in Agenda VR3 "Open" PDA, but it was more than 10 years ago), via
"hard but doable" (current gcc for Cortex-Mx whcih needs to be built twice
according to official instructions and which is released as one gigantic
source blob, not patches to official released sources) to "super-easy and
non-problematic" (Peter Bigot's msp430-gcc, but I need to say, that it was
easy and before Peter Bigot, with msp430-gcc3).
On the other hand, I don't understand, why vendor should provide binary
packages for any *IX-style system at all. These systems are different from
Windows (and, to some extent, from MacOS X) in the way software are
packages: here is OFFICIAL CENTRAL repository, and here are PACKAGE
MAINTAINERS, who are not "upstream" authors in most cases, It is work for
distributive authors to package BINARY programs and provide user way to
build binaries from sources with "one click" (think about Gentoo, if you
are not familiar with *BSD systems).
DB> people want to compile for the msp430 using OpenBSD on PPC processors,
DB> then it makes sense for TI to support that too - otherwise, unusual
DB> users can use the source and compile themselves.
Question is, how hard it will be -- to compile themselves. In my experience
in this area (more than 10 years for now) as soon as "vendor" provide
binaries for 1-2 popular platforms, and ESPECIALLY, if these binaries are
windows-style ("/opt/${soft}-${release}"), it is very hard to build proper
packages for other systems, especially for source-based ones (such as
Gentoo or FreeBSD), as build process is tailored to vendor needs, with some
script, additional stages, copying half-backed software to file system
hierarchy in pre-defined places, with hardcoded paths, etc. Of course, it
should not be such, but, again, in my experience it IS almost always.
Building msp430-gcc (with binutils, etc) is as easy as "configure" with
4-5 parameters for binutils, "gmake all install" for it, and then unpack
MCU headers (separate package! It is good!) repeat "configure-gmake" cycle
for GCC. It's all! (of course, you must apply patches from project, but,
again, there is strict, well-defined order of them, and it is not problem
at all). And after that system has 3 (4, with msp430-libc) well-defined,
well-behaved packages, with files in places, defined by system politics,
and not vendor decision. It is great! Simply!
And now, look at official ARM arm-gcc building script: it builds gcc
twice, it copy first copy of gcc somewhere, to remove later, it wants to
find some linux-specific headers in process, etc, etc, etc. Also, it uses
"sh" with bash-ism and some Linux-only utilities, which could be easily
replaced with POSIX ones. As usual in Linux world. Transform this in
well-behaved set of packages for any system, but targeted by authors, is hard.
DB> TI could (again in an ideal world) allow external maintainers here - if
DB> they don't want to maintain an OpenBSD repository themselves, but
DB> someone else is willing to do so, then TI could host it.
Nope. OpenBSD should. Any Open/Net/FreeBSD systems prefer to install
software from sources, locally built (think Gentoo in Linux world). There
are 3 branches of FreeBSD in active usage, cross number of platforms, for
example...
DB> When I write software for *nix, I use *nix philosophies. When I write
DB> software for Windows, I use Windows philosophies. When I write embedded
DB> software, I use embedded software philosophies.
Compiler is border ground here, of course.
>> Good toolchain should be based on official released sources (not some
>> obscure snapshots from binutils/gcc GIT), and be integrated in upstream
>> (so, it build should be as easy as "./configure --target-=msp430 && gmake
>> all install") or provided as one manageable patchset, not targeted for ANY
>> specific host (Ubuntu, Debian, Gentoo, Widnows, FreeBSD, whatever).
DB> Have you ever done embedded development work? Have you ever worked with
DB> gcc releases? Have you ever worked at getting changes for gcc into the
DB> upstream trees and then releases?
Yes, yes, and no. I'm maintaining (and using) msp430-gcc for FreeBSD for
about 5 years now :)
DB> files, and the latest libraries. This is the way Peter (and his
DB> predecessors) handled msp430
Please note, that way Peter handles msp430, I'm using as example of
excellent and third-party-maintainer-friendly way ;)
DB> No, Peter's method is not ideal for users - it is pretty good, and it is
DB> more than can be expected of him, but it is not quite complete. In
DB> particular, having source-only releases is a big barrier to many users
DB> (even Linux users). Obviously the source release is the most important,
Could you name Linux distro, which DOESN'T have Peter's
msp430-binutils/gcc/libc/headers in its OFFICIAL repo? Ok, maybe you could,
I don't know much about Linux distros, but even for "obscure" and "dead"
FreeBSD here is binary package, which could be installed by any user, with
system-provided package manager from system-provided repository without
adding any external ones. It is why (and for what) distros exists!
DB> and no one could possibly complain that Peter hasn't made pre-packaged
DB> bundles for different distros and OS's - but we /can/ expect that from a
DB> big company like TI.
Again, I repeat: every time I see "vendor-provided" binaries for 1-2
popular platform, I also see huge barriers to build (formally open-source)
software for not-so-popular platforms. It is especially true for
toolchains. If "new" msp430 toolchain port avoid this pitfall, I'll be
first, who buy beer for TI/RedHat developers, who make this port, if we
ever meet in flesh.
--
// Black Lion AKA Lev Serebryakov <l...@serebryakov.spb.ru>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
