On Wed, Jul 10, 2013 at 3:11 AM, David Brown <da...@westcontrol.com> wrote:
> That's no problem - I was also harsh, because my sore spot was > triggered. I feel very strongly about being able to control exact > release versions of toolchain releases (gcc, binutils, library), and > that people should be able to easily get older and newer releases at any > time, for any system, and know that matching release versions will > produce the same object code on any host system. The idea of putting an > embedded compiler as something like /usr/bin/msp430-gcc (or "c:\Program > Files\msp430-gcc\bin\msp430-gcc.exe") gives me the shivers - it makes > things easier for a newbie or amateur, but is worse than useless for a > serious or professional developer. > > I fully understand that as a fan of a minority-user OS, you have to > fight for your right to use the software you want on the OS you want - > and that the best way is aim for common *nix compatible source code. One item sadly missing from this discussion so far is the role of the package manager on Unix-based systems. In fact, much of this whole conversation has just made me cringe at various points. In the Unix world, package management is handled by a dedicated package manager. Different Unix systems have different package managers, each with different capabilities. In completely open source systems such as Linux, FreeBSD, and OpenBSD, the package managers are responsible for managing every file on the system. In commercial Unix systems such as Solaris and OS/X (MacOS) user-selected open source software packages are managed independently from system software. In the case of OS/X, there are no less than *three* package managers: MacPorts, HomeBrew and Fink. Every package management system has its own advantages and disadvantages and very few users are aware of the full capabilities of the package manager. For example, most package managers *do* allow for the concurrent installation of multiple packages. Furthermore, it is worth noting that package description files are often comminuty-built. For example, *anyone* can submit package description files to Debian. It is not the responsibility of the software author (in this case, Peter Bigot) to submit package description files or keep them updated. Since Debian package files are used for most Debian-derived systems (Ubuntu, Mint, etc.) submitting a package description file to Debian is usually sufficient for its eventual inclusion in the vast majority of systems. Finally, it is worth noting that package managers exist in part to take advantage of shared libraries. However, RAM is ridiculously cheap these days and even something as complex as GCC uses relatively little total code space. The penalty for building a statically-linked binary that will run on just about every Linux system is in most cases negligible. Since both FreeBSD and OpenBSD have Linux compatibility layers, this binary would run on those systems as well. To this end, I often recommend that new users simply install Energia because it is known to include fully patched and stable versions of mspgcc and mspdebug. -p. ------------------------------------------------------------------------------ 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
