On 08/07/13 16:20, Lev Serebryakov wrote:
> Hello, David.
> You wrote 8 июля 2013 г., 16:11:39:
>
> 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?
TI should (in an ideal world) have repositories containing toolchain
releases for their chips, in a form suitable for the most commonly used
platforms - and in source code for use on other platforms. If a lot of
people want to compile for the msp430 using OpenBSD on PPC processors,
then it makes sense for TI to support that too - otherwise, unusual
users can use the source and compile themselves.
TI could (again in an ideal world) allow external maintainers here - if
they don't want to maintain an OpenBSD repository themselves, but
someone else is willing to do so, then TI could host it.
>
> DB> supporting the toolchains for a variety of distros. But there should
> DB> not be packages such as "msp430-gcc" and "msp430-libc" in these
> DB> repositories - there should be packages such as
> DB> "msp430-release-20130708" containing all the toolchain. And these
> DB> should not contain files such as "/usr/bin/msp430-gcc" - they should
> DB> contain files such as "/opt/msp430-20130708/bin/msp430-gcc". Of course
> DB> such binaries should not be on the user's path - you must say exactly
> DB> which toolchain you want in your makefile (or Eclipse/CCS project setup).
> It is COMPLETELY out of unix-way! And, yes, what should FreeBSD users do
> in this your big-corporation-centric "ideal world", for example?
>
I don't develop /for/ unix - nor does anyone using the msp430. We
develop /using/ unix (some poor souls have to live with Windows for
development - but much the same applies to them).
When I write software for *nix, I use *nix philosophies. When I write
software for Windows, I use Windows philosophies. When I write embedded
software, I use embedded software philosophies.
And good embedded development practice says that changing any aspect of
your toolchain is a major change to your project, and it is not done
lightly. The toolchain is /part/ of your project. When you - or anyone
else - needs to do maintenance on an old project, you do not change the
toolchain just because there is a newer version out. You do not risk
unexpected problems because the new compiler has slightly different
behaviour, or the new library has a new bug. Compiling using whatever
version of /usr/bin/msp430-gcc you have on hand is simply unprofessional.
It is certainly possible for distro (Linux, *BSD, etc.) maintainers to
have msp430 packages in their normal repositories, but it is only a good
idea if they also follow the same sort of release numbering and avoid
general "latest version" releases. It only really makes sense for
"continuous update" or "rolling" distributions - a developer should not
have to update their entire OS in order to get a newer msp430 release,
and they should always be able to get older releases.
This is why I think it makes sense for these repositories to be separate
from the main distro repositories. I think it makes sense for TI to
host them - but it would also be possible to have them as third-party
hosted (in the same manner as Ubuntu PPA repositories).
Note that this is completely different from more "normal" programs, when
you are usually happy with the latest version - and updates will replace
older versions instead of being installed alongside them.
I am certainly not looking for a "big-corporation-centric" solution. I
work for a small company, and I am thinking small-developer-centric, and
I don't understand your thinking here. Perhaps I had not explained
myself very well.
> 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).
Have you ever done embedded development work? Have you ever worked with
gcc releases? Have you ever worked at getting changes for gcc into the
upstream trees and then releases?
gcc is a fantastic piece of work - both as software itself, and as a
project, and I have unbounded respect for the people working on it. But
one of it's biggest strength - it's flexibility, portability, and
configurability - is also its biggest weakness. It takes time to move
big changes (and sometimes even small changes) through the system and
into releases. It can take many months, or longer, for changes to make
their way to release versions - partly because it must be confirmed that
those changes don't disrupt any other working host-target combination.
Microcontroller manufacturers can't wait for that cycle, nor can users.
So the normal way of working is for the maintainers of an embedded
toolchain to base their build on a particular release of gcc, along with
patches to include support for the latest devices, the latest additions
to gcc (such as target-specific attributes), the latest device header
files, and the latest libraries. This is the way Peter (and his
predecessors) handled msp430, it is the way Atmel handles it for the
AVR, the way CodeSourcery handles it for the ports they maintain (MIPS,
ARM, PPC, and many others). The changes always (or almost always) get
merged into the upstream, but that process takes time.
The other big problem with working with upstream releases is that you
get one release for binutils, one release for gcc, and one release for
the libraries. To be useful to the end-user developer, you need a
single release covering all three - with the knowledge that these all
work together, and have all been tested together.
>
> It is work of OS/Distro maintainers to build binary packages for specific
> OS/Distro, in format, used in this OS/Distro. For example, FreeBSD doesn't
> have /opt at all! And, of course, it needs completely different binaries.
> And, of course, it is used to have ${target}-prefixed tools here!
>
> Peter's MSP430-gcc is IDEAL way to distribute OPEN SOURCE toolchain!
No, Peter's method is not ideal for users - it is pretty good, and it is
more than can be expected of him, but it is not quite complete. In
particular, having source-only releases is a big barrier to many users
(even Linux users). Obviously the source release is the most important,
and no one could possibly complain that Peter hasn't made pre-packaged
bundles for different distros and OS's - but we /can/ expect that from a
big company like TI.
Also note that in Peter's releases, he gives a set of specific upstream
releases combined with a set of release-specific patches. This is
/exactly/ the arrangement I want.
The only difference is that in addition to having this available as
source code, I also think it should be available as pre-built binaries
for commonly used development platforms, as a convenience to users. And
I want all such upstream+patches bundled releases to be available,
rather than just the latest versions, and I to avoid the idea that you
can have a "default" version of the tool.
>
> And I had enough this Linux- and corporate-centric shit in times of first
> Non-WinCE-based PD "Agenda VR3", which had toolchain in binary-only form,
> and sources looks like "get this snapshot of egcs3 and apply these 1348.5
> patches in order which is our trade secret"!
>
I think you would be entirely happy with the sort of system I am asking
for - but I was perhaps unclear in how I said it.
So - just to make sure there is no misunderstanding - let me say again
that I want binary releases in addition to source releases, not instead
of them. I want everything pushed upstream for the future, but I want
upstream+patch releases maintained and approved by TI (or Redhat, of
course) so that we don't have to wait for upstream. I want release
bundles that combine all three important parts of the toolchain - gcc,
binutils and libraries. (gdb, programmers, IDEs, and anything else can
be independent, as they don't affect the actual code.) And I want to be
able to easily get the very latest releases, and easily get all previous
releases, I want them all to be easily installed on the same system at
the same time, and I want them to work on a wide variety of development
hosts (with the source as a fall-back when needed).
I realise I want quite a lot here :-)
David
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
