[Tinyos Core WG] toolchain rationale

[Jan Beutel]

On Thu, 2006-11-16 at 14:03 -0800, David Gay wrote:
> On 11/16/06, Jan Beutel <j.beutel at ieee.org> wrote:
> > hello all,
> >
> > i wanted to know about the rationale behind the build toolchain assumed
> > for tos2. is there any thought process behind the currently assumed
> > version numbers, e.g. avr-libc 1.2.3 other than "individual likings"?
> > e.g. one version behind the current toplevel release?
> 
> Two major rationales:
> - No desire to constantly track the latest releases (it does take
> effort to do this)
> - Many past instances where particular versions do not work well
> enough to be used for TinyOS
> 
> These work together, i.e., the 2nd problem means that blindly tracking
> releases is a bad idea, so you have to spend more time whenever you
> decide to update.

yes. i agree. this argument was not in favor of blindly tracking... but
to sum up yours and phils comment it means that basically the tool/lib
versions that worked were deemed suitable for tinyos and updates where
only made where necessary. that sounds fine as a rationale.

> 
> > the reason i am asking is that i have not been a friend of the many
> > steps involved in getting TOS going, let alone the chance of a windows
> > installation surviving a simultaneous "clean" tos2 environment and for
> > example boomerang 2.0.3 and 2.04 on the same machine. i know this is not
> > the common case... and most people will be happy with the original 1.x
> > one click windows installer and possibly some extra rpms.
> >
> > moreover, there are people that want/have to install in other
> > directories than /opt and /usr and this currently involved patching up
> > ncc and nescc everytime there is a new tool release. not very difficult,
> > but nasty. (e.g. on a department-wide cluster of workstations used for
> > student activities...)
> 
> FWIW, the usual Unix-style tool build process is not friendly to
> relocating packages (just try relocating your typical Linux package).
> While this is always fixable w/ enough effort, it doesn't seem
> particularly worthwhile (and often comes at the cost of other
> problems, e.g., dependencies on environment variable settings). We
> have, in the past at least, tried to make it possible to relocate the
> tinyos package itself.

yep. there are ways, e.g. sepp, to make it more comfortable. but again,
this is yet another technology, many people do not want to care about.

to make it worse the problem about the relocation or multiple tinyos
trees on one system always is connected to the right toolchain. but
maybe tos2 is a good way of consolidating this a bit more....

> 
> And while I'm on the topic of supporting tools: I am no longer in the
> business of building and testing them. So if you, or anybody else,
> wants to take over that task and fix these various issues, I'm sure
> everybody will be happy :-) (especially as time passes and the current
> tools become more obsolete).

ok david. thanx for the offer. you will hear from me...

basically there are two issues with the current toolchain that make it
cumbersome to install/move:

- avr-libc has deprecated avr/signal.h in versions > 1.4.x
- ncc and nescc assume absolute install paths

jan


> 
> David Gay
-- 
Dr. Jan Beutel                              j.beutel at ieee.org
Computer Engineering and Networks Laboratory, ETZ G75
ETH Zurich                             +41 44 632 70 32 Phone
Gloriastrasse 35                         +41 44 632 10 35 Fax
CH 8092 Zurich/Switzerland  http://www.tik.ee.ethz.ch/~beutel