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

[Philip Levis]

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