[Tinyos-host-mote-wg] RE: [Tinyos-2.0wg] packages for nesC: why/etc [shortish so you canglance through it this morning]

[Buonadonna, Phil]

Coming from EmNets, the biggest (and most concrete) complain from nesc
users is the surmounting difficulty of navigating the TOS
directory/namespace.  Answering the question "which component is my
program using" is becoming increasingly complex. 

I assume the package system would help address this problem? If yes,
then this is a much needed thing.

Going from #include back to 'includes' isn't to hard.  However, it
sounds like integrating a C-preprocessor in nesC quite a bit of work. 

would the package system impact source-line debugging?

pb



> -----Original Message-----
> From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU 
> [mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On 
> Behalf Of David Gay
> Sent: Wednesday, June 01, 2005 9:32 AM
> To: tinyos2
> Subject: [Tinyos-2.0wg] packages for nesC: why/etc [shortish 
> so you canglance through it this morning]
> 
> Name space for tinyos components and interfaces is getting complex:
> 
>   - similar names needed for functionality at many layers:
>     hpl, hal, hil, oski
>   - similar names needed across platforms / chips
>   - some components are "private": not intended for independent use
>     (lookup, e.g., at tos/lib/FS in 1.x)
> 
> Prefixing is not a good solution: names become very awkward, 
> prefixes are not
> used consistently, etc.
> 
> ------------
> 
> Proposal: add a package system to nesC
> 
>   packages contain component and interface files, and other packages
>   issue: what about C names and include files? (see below)
> 
>   packages must be imported in a file before use
>   packages can be imported with a "private" name
>    (something like import "tinyos.lib.adc as foo", followed by uses
>     like foo.SomeAdcInterface)
>   some set of packages are automatically imported
> 
> --------------
> 
> Major issues:
> - how to deal with C names?
> - how to deal with C files, preprocessor macros?
> i.e., are they part of the package system, which means that:
>   - C file inclusion should either include the package name, or
>     be searched for in imported packages
>   - C names/preprocessor names would be searched for in imported
>     packages (and support the importedasname.name syntax)
> 
> Reasons to include them:
> - same as for components and interfaces: the packages will 
> need to organise
>   their type names, etc
> 
> Reasons not to include them:
> - how does #include work within a package system?
>   (short answer: it doesn't, we would need to go back to 
> "includes foo;")
>   (long answer on request)
> - macroprocessing currently handled by external gcc invocation
>   --> cannot handle macros in packages
>       solution: integrate preprocessing into nesC compiler
>                 this allows "includes" and macros to work together...
> - more changes from C, possible syntax issues
> 
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/
> tinyos-2.0wg
> 

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg