[Tinyos-2.0wg] Re: tinyos-2-0-0-beta2-candidate

[Kristin Wright]

Last-minute check: are we 100% ready for the -2 release rpms to be built?
-kw

On 7/4/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Jul 4, 2006, at 11:40 AM, Vlado Handziski wrote:
>
> >
> > What about a new tinyos RPM with the remaining testing apps? I have
> > finished the testing of the current RPM on eyesIFX and everything
> > seems OK, apart from the Sense applications output (showing MSB vs.
> > LSB bits). I have only tested on Linux, I don't have the msp430
> > tools for cygwin.
>
> Apologies; we clearly need a second TinyOS RPM. I just thought that
> this was so clear that I, um, failed to mention it. :) I've checked
> in changes to the file lists that should include the additional test
> apps and moved some additional files over to the release branch.  I
> incorporated Jan's updates to the MSP430 ADC that uses the MSBs.
> Right now we're just waiting for Kristin to cut the RPMs.
>
> >
> >
> > General:
> >
> > While I understand the benefits of having common .spec files for
> > cygwin and linux, I think that we are ending up with packages that
> > do not provide "turn-key" solution on linux and can confuse a lot
> > of early users. The main problems that I see are:
> >
> > - the packages are not fully relocatable with  --prefix. I think
> > that by default we should install all binaries in /opt and use /etc/
> > profile.d/xxx.sh /etc/profile.d/xxx.tcsh to amend the paths.
> >
> > - the packages are not properly setting the permissions to the
> > serial devices and the ownership of the /opt/tinyos- 2.x files is
> > left to be root.root
> >
> > We have solved all of the issues above in our eyesIFX installer kit:
> >
> > https://wg.tkn.tu-berlin.de/twiki/bin/view/WSN/
> > EyesIFXDevelopmentKitSoftwarePackageInstallation
> >
> > (the .spec files and the separate RPMs on the wiki are not the
> > latest versions, I will fix this tomorrow. The GEKSI archive is
> > current though)
> >
> > If we decide to provide separate linux and windows RPMs, we can
> > reuse the solutions from the kit to provide "turn-key" RPM packages
> > that provide all the necessary setup on FC.
> >
> > App makefiles:
> >
> > By creating the java and python message files by default we are
> > introducing a large dependency for the users that don't wand any PC
> > support. They should be created on demand or we should add
> > "detection logic" and build only the message stubs for the language
> > that the user has installed or has selected as option during the
> > installation of the RPMs.
>
> Do you mean in applications, or in the actual sdk? Another thought
> might be to add targets for sdks in support/make (if the system would
> support that). E.g., you can do a
>
> make micaz sdk-python
>
> That seems simpler and preferable to automatically sensing languages.
> Especially if you decide you want to use another sdk but the option
> was set at RPM installation...
>
> > Also, please consider using a variable for the java compiler in the
> > Makefiles. In many cases we need to change JAVAC=gcj -C to get gcc-
> > java support. The only thing currently not working with gcj is the
> > Oscilloscope application because of missing widgets.
> >
>
> Let's keep javac for the beta2. For the next release, we can look
> into having a JAVAC= in the Makedefaults and letting a Makelocal
> override it. I understand that you'd like to use gcj, but that does
> seem like an edge case for now, especially since Oscilloscope does
> not compile.
>
> Phil
>
>
>
>
>