On 09/07/13 09:03, Lev Serebryakov wrote:
> 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).
I agree here, and I've seen mixes too between hard and easy. One thing
that can make a big difference is dependencies - it is useful to have a
list of the required build dependencies, including the variants for
Debian-style and Redhat-style distros (and BSDs :-). Another thing is
if there are many patches, then you want a tarball of the patches or a
script that will download and apply the patches - it can save a lot of
time and annoying errors. I believe the double-build is due to first
doing a "bootstrap" build without any libraries, then building some
libraries, then doing a full build - and I think this is no longer
necessary with current gcc. But I could be wrong - the only gcc build
I've done in the past few years is Peter's msp430-gcc, and as you say it
is "super-easy".
>
> 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).
Having the packages maintained by the distro is great for many things -
but it is also a pain for some types of software. It is particularly
inconvenient for software that must be updated regularly (such as
browsers), and for software where you might want many different versions
(such as embedded development tools). There are advantages in having
vendors provide binaries too. While I think the standard Linux (and
BSD) way is best for most purposes, it is not the best for everything.
>
> 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.
Putting things in a release-specific directory is certainly not "windows
style". "Windows style" is to overwrite your current version with the
new version, preferably without asking you. *nix style is to overwrite
your current version with the new version (unless it's a library), but
ask you if this means downgrading. I don't want Windows-style or
*nix-style for my embedded tools - I want old and new versions to
coexist, in directories with unambiguous names.
>
> 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!
I realise you think this is great - and it is certainly great that this
method is possible. But it is /not/ great for many users who do not
want to have to put things together by hand. And it is /not/ great for
a company or development group, where all the users make their own
toolchains with slightly different configurations. And it is /not/
great for people who missed out one of the patches, and get unexpected
errors. And it is /not/ great for the toolchain maintainers who have to
deal with bug reports from said user, who thinks he has that patch
installed but in fact does not.
>
> 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...
>
If that's how BSD folks like things, that I see no problem with that.
But that is not how most Linux users want things, and certainly not how
Windows or Mac users want them. Many Linux users are /professional/
developers. Time is money. If I had no experience building toolchains,
it might take several hours to read about what I am supposed to do, get
all the bits, run the builds, find out why the build failed, install the
missing dependencies, re-do the build, find where the tools ended up,
test them, etc. It's not long before the "free" toolchain costs more
than buying commercial toolchains from IAR or others. And it only takes
a single incidence of incorrect code due to mistakes in the build
process to make gcc very expensive.
> 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!
To my knowledge, there are no Linux distros that have proper msp430-gcc
support. (I can't answer for BSDs.) By that I mean that there are no
distros that have regular tracking of the latest versions, that have
easily available previous versions, that have packaged them in a way
that makes it possible to have multiple versions installed at the same
time, and have packaged them in a way that makes it easy to get a
consistent release of all parts of the toolchain, and that add and
support newer versions long after that particular distro version is no
longer officially supported.
>
> 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.
>
------------------------------------------------------------------------------
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
