nescc-devel — Developers of the NesC compiler and related tools.

Re: [nescc-devel] [Tinyos-devel] nesC version 1.3.5

[David G. <dg...@gm...>]

On Tue, Jun 18, 2013 at 12:17 AM, Eric Decker <ci...@gm...> wrote:

> can you also please tag the appropiate place in the dev tree that
> corresponds to the release?
>

Done.


>
> If one currently builds from the tip does it do the same thing as the tar
> ball?
>

Yes.


>
>
> On Mon, Jun 17, 2013 at 11:34 PM, David Gay <dg...@gm...> wrote:
>
>> Version 1.3.5 of the nesC compiler is now available from
>>
>> http://sourceforge.net/projects/nescc/files/nescc/v1.3.5/nesc-1.3.5.tar.gz/download
>>
>> Changes in nesC 1.3.5
>> =====================
>> - improved man pages
>> - new option (-Wnesc-implicit-conn) to warn when using implicit
>> connections
>>   (interface = commponent)
>> - fix interfaces with mutiply-parameterized interfaces
>>   (http://sourceforge.net/p/nescc/bugs/69/)
>> - make lookups of symbols using the magic __nesc_keyword_ prefix lookup
>> the
>>   non-prefixed symbol (fixes https://github.com/tinyos/nesc/issues/4)
>> - nescc-mig, nescc-ncg now recognize --param, -imultilib, -isysroot and
>>   -Xpreprocessor as options taking arguments
>>
>> David Gay
>>
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tin...@mi...
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>

[nescc-devel] nesC version 1.3.5

[David G. <dg...@gm...>]

Version 1.3.5 of the nesC compiler is now available from

http://sourceforge.net/projects/nescc/files/nescc/v1.3.5/nesc-1.3.5.tar.gz/download

Changes in nesC 1.3.5
=====================
- improved man pages
- new option (-Wnesc-implicit-conn) to warn when using implicit connections
  (interface = commponent)
- fix interfaces with mutiply-parameterized interfaces
  (http://sourceforge.net/p/nescc/bugs/69/)
- make lookups of symbols using the magic __nesc_keyword_ prefix lookup the
  non-prefixed symbol (fixes https://github.com/tinyos/nesc/issues/4)
- nescc-mig, nescc-ncg now recognize --param, -imultilib, -isysroot and
  -Xpreprocessor as options taking arguments

David Gay

[nescc-devel] nesC 1.3.4 released

[David G. <dg...@gm...>]

http://sourceforge.net/projects/nescc/files/nescc/v1.3.4/nesc-1.3.4.tar.gz/download

Changes in nesC 1.3.4
=====================
- support gcc 4.7.x (issue 3381025)
- fix issues 3519555, 3473487, 3468269

David Gay

Re: [nescc-devel] gcc 4.7 and nesc issues

[David G. <dg...@gm...>]

On Mon, Apr 9, 2012 at 1:25 AM, Eric Decker <ci...@gm...> wrote:
> Hi David,
>
> We need your help.
>
> Peter has been busy working on advancing the msp430 toolchain to using more
> modern versions of gcc.
>
> The most recent release is based on gcc 4.6.3.   It does not have 20 bit
> support.   20 bit support is highly desirable as we are running out of code
> space for non-trivial applications and the newer TI MSP430 cpus support
> larger addresses.  In particular, I'm personally interested in the 256K rom
> space of the msp430f5438a for the mote we are developing.  We have already
> run out of space for our application and the larger address space will help
> ease the pressure.
>
> For technical reasons, 20 bit support requires moving to gcc 4.7 and
> associated binutils.   And that is where the problem arises.  nesc uses a
> previous behavior of gcc that allows the use of special options used by
> nesc.   These have been explicitly disallowed in 4.7.
>
> So currently, 4.7 is required for 20 bit support but the restriction on
> using special option switches renders 4.7 incompatible with nesc.  Ouch.
>
> We need your help figuring out how to deal with this so we can get 20 bit
> support available for tinyos on advanced TI msp430 processors.
>
> Peter's bug report for nesc can be found at:
>  http://sourceforge.net/tracker/?func=detail&aid=3381025&group_id=56288&atid=480036
>
>
> And more details as given by Peter to the gcc project can be found
> at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858
>
>
> I hope you can help us figure this out.

I've revamped the option handling between nescc and nesc-compile/nesc1
to use environment variables, to work around the gcc-4.7 option
handling changes.

This is checked into CVS, and I've done some brief testing w/ avr-gcc
(4.0) and gcc 4.7 (sim target). However, I can't easily test all
possible platform/option combinations, so please test and send me any
bug reports...

I'll make a 1.3.4 release when we're confident this is stable.

David

>
> thanks,
>
> eric
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>

[nescc-devel] Fwd: nesC 1.3.3

[David G. <dg...@gm...>]

This has been on sourceforge for a little while, but I just made it
the default version.

David Gay

Changes in nesC 1.3.3
=====================
- fixed mig when used with perl 5.12 (sourceforge bugs 3122329, 3066006)
- work around potential gcc 4.6 behavior change (sourceforge bug 3153727)
- support gcc's -H option (print #included file names)

[nescc-devel] Re-Generate Makefile.in

[Tarion <Ta...@ni...>]

Hi,
I'm working on the nescc in my student project. When I use Bootstrap to
create the new Makefile.in I get the follwoing output wich leads to the
[COMPILER ERROR] blow.

[BOOTSTRAP]
sitk0939@thermioc:~/svn/nse/trunk/nesc-1.3.2$ ./Bootstrap
+ aclocal
+ autoconf
+ [ -d config-aux ]
+ automake -a -c
+ cd src
+ aclocal -I ../config-aux
configure.in:64: warning: macro `AM_ICONV' not found in library
+ autoheader
+ autoconf
+ automake -a -c
libcompat/Makefile.am:21: `:='-style assignments are not portable
+ cd ..
+ cd libiberty
+ autoheader
configure.ac:634: warning: AC_LIBOBJ($funcs): you should use literals
../../lib/autoconf/general.m4:2929: AC_LIBOBJ is expanded from...
../../lib/m4sugar/m4sh.m4:598: AS_IF is expanded from...
../../lib/autoconf/functions.m4:60: AC_CHECK_FUNC is expanded from...
../../lib/autoconf/functions.m4:133: AC_REPLACE_FUNCS is expanded from...
configure.ac:634: the top level
+ autoconf
configure.ac:634: warning: AC_LIBOBJ($funcs): you should use literals
../../lib/autoconf/general.m4:2929: AC_LIBOBJ is expanded from...
../../lib/m4sugar/m4sh.m4:598: AS_IF is expanded from...
../../lib/autoconf/functions.m4:60: AC_CHECK_FUNC is expanded from...
../../lib/autoconf/functions.m4:133: AC_REPLACE_FUNCS is expanded from...
configure.ac:634: the top level
+ cd ..
+ cd libcpp
+ aclocal -I ../config-aux
configure.ac:81: warning: macro `AM_ICONV' not found in library
+ autoheader
+ autoconf
configure.ac:81: error: possibly undefined macro: AM_ICONV
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.


---

[COMPILER ERROR]

> ranlib libparser.a

gcc -DHAVE_CONFIG_H -I.  -I./libcompat -I./../libcpp/include -I./../libcpp
> -I./../include      -g -Wall -Wno-long-double -MT toplev.o -MD -MP -MF
> .deps/toplev.Tpo -c -o toplev.o toplev.c

mv -f .deps/toplev.Tpo .deps/toplev.Po

gcc  -g -Wall -Wno-long-double   -o nesc1 toplev.o libparser.a
> libcompat/libregions.a ../libcpp/libcpp.a ../libiberty/libiberty.a -lm
> @LIBICONV@

gcc: @LIBICONV@: No such file or directory

make[3]: *** [nesc1] Fehler 1

make[3]: Verlasse Verzeichnis
> '/studhome/sitk0939/svn/nse/trunk/nesc-1.3.2/src'

make[2]: *** [all-recursive] Fehler 1

make[2]: Verlasse Verzeichnis
> '/studhome/sitk0939/svn/nse/trunk/nesc-1.3.2/src'

make[1]: *** [all] Fehler 2

make[1]: Verlasse Verzeichnis
> '/studhome/sitk0939/svn/nse/trunk/nesc-1.3.2/src'

make: *** [all-recursive] Fehler 1




---

I solved the Error:
configure.in:64: warning: macro `AM_ICONV' not found in library
by installing gettext.

Now I get an Error on ./Configure --prefix="/my/path/to/nesc"

checking whether gcc supports -pedantic -Wno-long-long... yes

./configure: line 3787: ZW_CREATE_DEPDIR: command not found

./configure: line 3788: syntax error near unexpected token `CC'

./configure: line 3788: `ZW_PROG_COMPILER_DEPENDENCIES(CC)'

make[1]: *** [config.status] Fehler 2

make[1]: Verlasse Verzeichnis
> '/studhome/sitk0939/svn/nse/trunk/nesc-1.3.2/libcpp'

make: *** [all-recursive] Fehler 1


Where can I find a list of required tools?

Greetings, Tobi

[nescc-devel] nesC 1.3.2 now available for download from sourceforge (source)

[David G. <dg...@gm...>]

Changes in nesC 1.3.2
=====================
- changed Intel Open Source License files to dual BSD/GPL license
- improved support for non-gcc targets: -fnesc-gccize flag,
  optionally identify "async" function in nescc output
- bug fixes (sourceforge bugs 3013497, 3017203, 3019357 and others)
- disable use of Apple-specific "blocks" C extension

--
David Gay
dg...@ac...

[nescc-devel] nesC 1.3.2 release candidate

[David G. <dg...@gm...>]

I've put a release candidate tarball of nesC 1.3.2 at
http://barnowl.org/nesc-1.3.2-rc.tar.gz

Could at least some of you fetch, compile and use this release to
confirm that there are no problems before I actually release it? (and
let me know that you have ;-))

The following summarises the changes in this release:
- changed Intel Open Source License files to dual BSD/GPL license
- improved support for non-gcc targets: -fnesc-gccize flag,
  optionally identify "async" function in nescc output
- bug fixes (sourceforge bugs 3013497, 3017203, 3019357 and others)
- disable use of Apple-specific "blocks" C extension

--
David Gay
dg...@ac...

[nescc-devel] Outputing async info

[Martin L. <le...@di...>]

Hi All.
In the TinyOS 8051 wg we would like to be able to dump some information
about which functions that are called from async context. The reason we
want this info, comes from optimisations that are usually applied in
8051 compilers -  functions are not reentrant by default, but have to be
marked individually, and we would like to use the async annotation from
nesc to do that.

As far as I can tell the -fnesc-dump system only dumps information on
the input program, not on the generated code, but what I would like to
do is be able to do something like a dump on all functions that are
analyse to be async by nesc.

How is not particularly important, but I have attached two patches to
illustrate what I'm thinking - neither is particularly pretty, so please
share your thoughts on what a real solution could look like.
async_filter
 Adds an "async" filter, to allow something like
   -fnesc-dump=functions(async)
async_attribute:
 A quick-and-dirty hack to make Nesc add an __attribute((async))


The slightly longer explanation as to why, is the following. As a way
around the limited 8051 stack, Keil (and others) uses two optimisations:
first a compile time stack and second it uses overlaying between
separate compile-time stack elements. This approach has the drawback
that all functions are by default non-reentrant. Which means that unless
great care is taken the generated code could be severely broken (e.g.
interrupt handlers). As a result Keil analyses the code and identifies
all culprits, but it has no feature to automatically apply the
appropriate fix - it relies on the user to understand and react to the
warning.

As we are using Keil to compile Nesc generated code this is highly
unlikely. And even if appropriate markings are made in the source, the
output may still contain nesc-glue functions that did not exist in the
input. Disabling the optimisations altogether is not very attractive
either, since this has a major impact on performance.

Our current hack relies on using the warning from a previous Keil run to
mark function in the next run. This is not very elegant and limited to
Keil. We would like a general solution that would work with other
compilers as well and we believe that taking advantage of the async
context of TinyOS would be one way to do that.

-- 
Regards Martin Leopold.

[nescc-devel] nesC 1.3.1

[David G. <dg...@gm...>]

This is basically a bug-fix release (a collection of minor bugs). I'm
assuming the usual suspects will make a nice binary distribution to go
with TinyOS 2.1.1? It would be good if some of you could use it a bit
before then too...

The source tarball is at https://sourceforge.net/projects/nescc/.

David

Changes in nesC 1.3.1
=====================
- updated reference manual for language changes since version 1.2.0
- support gcc's -include option when compiling a nesC application
- bug fixes

[nescc-devel] Mini nesC internals doc at http://docs.tinyos.net/index.php/Nesc-internals

[David G. <dg...@gm...>]

Subject says it all. This isn't attempting to be complete, but rather
to provide some initial guidance for anyone who needs/wants to look at
the nesC compiler internals. If you do that, then I encourage you to
edit the above wiki pages to provide extra information for future
explorers ;-)

I'm checking the wiki source for these pages into the sourceforge too,
for archival purposes. The wiki version should be assumed to be the
authoritative one...

David Gay

[nescc-devel] nesC 1.3.0

[David G. <dg...@gm...>]

I'm pleased to announce the release of nesC 1.3.0, which adds support
for the Deputy type-safety annotations to nesC. Deputy
(http://deputy.cs.berkeley.edu) is a system of light-weight
annotations for providing type safety to C (and C-like) languages,
with reasonable overhead.

nesC 1.3.0 should also provide substantially faster compilation,
especially on Windows.

nesC is available in source form from
http://sourceforge.net/project/showfiles.php?group_id=56288. Debian,
Fedora and Cygwin packages will follow soon.

David Gay

Changes in nesC 1.3.0
=====================
- C preprocessor is integrated into nesC, which should significantly speed
  up compilation (esp. on Windows)

- support for the Deputy type-safety-for-C system (see
  deputy.cs.berkeley.edu). To use Deputy, you add type annotations to
  your nesC code, then compile with the -fnesc-deputy flag. A bunch of
  small changes to nesC support the use of deputy.

  Flags to nescc:
  -fnesc-deputy: use Deputy in this compilation. You need to have
   a version of Deputy customized for use with nesC installed for
   this to work.
  -fnesc-deputy-args: extra arguments to pass to Deputy.
  -fnesc-default-safe/-fnesc-default-unsafe: the default safety for
   C functions and nesC modules (with no option specified,
   -fnesc-default-unsafe is assumed)

  Type annotations: NONULL, COUNT(...), etc (see the Deputy-for-nesC
  documentation for full details), which are actually macros which
  expand to nesC attributes (@nonnull(), @count(...), etc. Using macros
  allows Deputy-annotated code to be used with earlier versions of nesC.

  Type annotations in nesdoc comments: to reduce clutter for non-Deputy
  users, Deputy's annotations can be placed within a nesdoc comment
  rather than in a function signature (which then looks like a regular
  C signature):
    /** ... @param 'int *@count(n) x' x is an array of n ints ... */
    void f(int *x, int n);
  is the same as
    void f(int *@count(n) x, int n);
  Macros can be used in the comment, so the above could also be
    /** ... @param 'int *COUNT(n) x' x is an array of n ints ... */
    void f(int *x, int n);
  where COUNT(expr) expands to @count(expr).

- internal support (in nesc1) for Deputy based on @deputy_scope() and
  @macro("NAME") attributes, and a -fnesc-genprefix=<line> option.

- @macro() and -fnesc-genprerix= may be useful in other contexts too:
  if a nesC attribute declaration has an @macro() attribute:
    struct @myattr @macro("MYMACRO") { int x; char *y; };
  then uses of @myattr in nesC source are output as calls to MYMACRO in
  nesC's intermediate C output. For instance
    int x @myattr(23, "fun");
  becomes
    int x MYMACRO(23, "fun");
  The -fnesc-genprefix=<line> adds <line> to the start of the generated C
  output, e.g., it could be a #define definition for MYMACRO, or a
  #include of a file with appropriate definitions.

- wide strings in XML output now show up as arrays of bytes (and follow
  the target's byte-level representation of wide strings)

- ability to process a C file through nesC (this provides support in C for
  external types, atomic statements and unique), as follows:
    nescc <options> -x nesc <filename>.c
  This forces nescc to pass the C file <filename>.c through the nesC compiler
  (normally it would be sent to the regular C compiler), which will process
  the nesC extensions and then compile the generated C code with the regular
  C compiler (or whatever compiler was specified with -fnesc-gcc=...)

- inside a module, you can now write void f(void) or void f() interchangeably

Re: [nescc-devel] [Tinyos-devel] Testing: RC3

[David G. <dg...@gm...>]

On Mon, Jul 14, 2008 at 10:15 AM, David Gay <dg...@gm...> wrote:
> You may want to wait a couple of hours for nesC 1.3 beta6, w/  a fix
> for a bug w/ network bitfield types found by Razvan...

Ok, beta6 is on sourceforge... Kevin, can you make the debs?

David

[nescc-devel] nesC 1.3.0 beta5

[David G. <dg...@gm...>]

Now with less warnings when using network types in safe compilations!

David

Re: [nescc-devel] [Tinyos-devel] nesC 1.3.0 beta3

[Philip L. <pa...@cs...>]

On Jun 24, 2008, at 7:44 PM, Razvan Musaloiu-E. wrote:

>> It also makes branching a little easier. Git has these benefits, plus
>> the ability to maintain a local repository.
>
> I consider this a very useful feature but I know that Phil  
> doesn't. :-(

I think the local repository is kind of neat. But basically, I'm wary  
of going back to someone periodically losing four hours debugging  
because someone accidentally checked in a change to the AM group.

My experience is that the time managing branches in CVS is a little  
tricky is when the branched-from code progresses independently. In  
TinyOS, development tends to be such that a given file has very few  
people who modify it. So branching out, then merging it back in is not  
a big deal, as long as you are careful to tag when you branch.

>>
> How about moving the tinyos-2.x to SVN and keeping the tinyos-2- 
> contrib in CVS?
>

When we set up contrib, it seemed really important to have contrib in  
the same repository as TinyOS itself, to increase its visibility.

> Another thing that makes SF very annoying is the fact that is very- 
> very slow from time to time. Sometime in the most inappropriate  
> moments. :|

Fair enough -- but I'm not sure that it's worse than any other  
provider in this regard. And not having to worry about physical  
machines, the integrity of data, or the longevity of the site, is a  
big relief.

Phil

Re: [nescc-devel] nesC 1.3.0 beta3

[Philip L. <pa...@cs...>]

On Jun 23, 2008, at 3:15 PM, Vlado Handziski wrote:

> I think it is high time that we drop SF. We can either move to git  
> or svn. We can host a public repo on Google or github or whatever.  
> And this being an open source project, with a very limited set of  
> people that commit to the repository, we can live perfectly well  
> without the fine grained per folder access controls. The peer  
> pressure to keep the HEAD or trunk or whatever in working state is  
> more than enough.


Access permissions come from 1.x, and when contrib was a subdirectory.  
Even now, as a separate module, write access to 2.x contrib provides  
write access to the entire tree. Without per-directory permissions,  
this means any and all contrib parties can write to tos/. I'd agree  
that a limited number of people commit to tos/, tools/, and support/.  
Contrib is a wholly different story.

The motivation for this limitation is maintenance. There are certain  
configuration variables and files which users often change in their  
local installations. E.g., the default frequency for mica2, the AM  
group, the 15.4 channel. By giving any and all contrib parties write  
access to the main tree, this in some ways raises the bar of the  
degree of care they have to apply when committing, and also means that  
the people maintaining the core need to be more vigilant about  
watching commits. The commit that removed the LPL warnings is a recent  
example. There were many cases in 1.0/1.1 where developers (contrib  
and otherwise) accidentally checked in changes which broke other  
people's code and led to days of debugging to find the source.  
Avoiding that kind of hair-pulling is good.

As far as I see it, svn has two major advantages over CVS, neither of  
which seem to be a big issue that we find painful:

1) Atomic commits
2) Can move directories

It also makes branching a little easier. Git has these benefits, plus  
the ability to maintain a local repository.

Which of these is a pressing problem whose cost outweighs the  
maintenance benefit of access permissions?

Phil

Re: [nescc-devel] [Tinyos-devel] nesC 1.3.0 beta3

[David G. <dg...@gm...>]

On Mon, Jun 23, 2008 at 3:59 PM, David Gay <dg...@gm...> wrote:
> On Mon, Jun 23, 2008 at 3:54 PM, Kevin Klues <kl...@gm...> wrote:
>> Should I regenerate a deb pacakge for the repo then from nesc cvs?  Or
>> is there a beta4 coming up soon?
>
> Let me finish my testing first (hopefully soon).

Ok, there's a beta4 on sourceforge with:
beta4:
- fix misc bugs (nesdoc, safe/unsafe tasks, problems with gcc 4.0.x)

David

Re: [nescc-devel] [Tinyos-devel] nesC 1.3.0 beta3

[David G. <dg...@gm...>]

On Mon, Jun 23, 2008 at 3:54 PM, Kevin Klues <kl...@gm...> wrote:
> Should I regenerate a deb pacakge for the repo then from nesc cvs?  Or
> is there a beta4 coming up soon?

Let me finish my testing first (hopefully soon).

David

Re: [nescc-devel] nesC 1.3.0 beta3

[David G. <dg...@gm...>]

On Mon, Jun 23, 2008 at 2:54 PM, David Gay <dg...@gm...> wrote:
> Should be fixed in CVS head (along with Kevin's problem) as soon as
> sourceforge is happy again.

Committed.

David

Re: [nescc-devel] nesC 1.3.0 beta3

[Vlado H. <han...@tk...>]

I think it is high time that we drop SF. We can either move to git or svn.
We can host a public repo on Google or github or whatever. And this being an
open source project, with a very limited set of people that commit to the
repository, we can live perfectly well without the fine grained per folder
access controls. The peer pressure to keep the HEAD or trunk or whatever in
working state is more than enough.

Vlado

On Mon, Jun 23, 2008 at 23:54, David Gay <dg...@gm...> wrote:

> Should be fixed in CVS head (along with Kevin's problem) as soon as
> sourceforge is happy again.
>
> David
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> nescc-devel mailing list
> nes...@li...
> https://lists.sourceforge.net/lists/listinfo/nescc-devel
>

Re: [nescc-devel] nesC 1.3.0 beta3

[David G. <dg...@gm...>]

Should be fixed in CVS head (along with Kevin's problem) as soon as
sourceforge is happy again.

David

Re: [nescc-devel] [Tinyos-devel] nesC 1.3.0 beta2

[David G. <dg...@gm...>]

You'll have to show cdefs.h for me to derive anything useful from that
(it's unlikely to be a beta3 vs 2 or 1 issue).

David

On Sun, Jun 22, 2008 at 1:24 PM, Kevin Klues <kl...@gm...> wrote:
> tinyos-2.x/support/sdk/java does not compile with nesc-1.3beta3
>
> ncg -o Serial.java -java-classname=net.tinyos.packet.Serial java
> /home/klueska/sensornets/tos/tinyos-2.x/tos/lib/serial/Serial.h
> Serial.h
> In file included from /usr/include/features.h:323,
>                 from /usr/include/inttypes.h:26,
>                 from /usr/lib/ncc/nesc_nx.h:16:
> /usr/include/sys/cdefs.h:32:3: error: #error "You need a ISO C
> conforming compiler to use the glibc headers"
> In file included from /usr/include/math.h:94,
>                 from
> /home/klueska/sensornets/tos/tinyos-2.x/tos/system/tos.h:15:
> /usr/include/bits/mathcalls.h:55: syntax error before `f'
> /usr/include/bits/mathcalls.h:55: syntax error before `f'
> /usr/include/bits/mathcalls.h:57: syntax error before `f'
> /usr/include/bits/mathcalls.h:57: syntax error before `f'
> /usr/include/bits/mathcalls.h:59: syntax error before `f'
> /usr/include/bits/mathcalls.h:59: syntax error before `f'
> ...
> ...
>
> Kevin
>
> On Fri, Jun 20, 2008 at 2:01 AM, Kevin Klues <kl...@gm...> wrote:
>> I already made the change from the full beta3 'release' just update
>> from the repository.
>>
>> Kevin
>>
>> On Thu, Jun 19, 2008 at 8:33 PM, David Gay <dg...@gm...> wrote:
>>> On Thu, Jun 19, 2008 at 3:23 PM, Kevin Klues <kl...@gm...> wrote:
>>>> Can I just add this folder and then repackage the deb?  Or are there
>>>> other changes to beta3 as well?
>>>
>>> Actually the change is to the path the file is found by - you could
>>> just add the link instead (it's the quick version of fixing the path),
>>> but I don't know if debs like soft links.
>>>
>>> David
>>>
>>
>>
>>
>> --
>> ~Kevin
>>
>
>
>
> --
> ~Kevin
>

Re: [nescc-devel] [Tinyos-devel] nesC 1.3.0 beta2

[David G. <dg...@gm...>]

On Thu, Jun 19, 2008 at 3:23 PM, Kevin Klues <kl...@gm...> wrote:
> Can I just add this folder and then repackage the deb?  Or are there
> other changes to beta3 as well?

Actually the change is to the path the file is found by - you could
just add the link instead (it's the quick version of fixing the path),
but I don't know if debs like soft links.

David

Re: [nescc-devel] nesC 1.3.0 beta2

[David G. <dg...@gm...>]

On Thu, Jun 19, 2008 at 3:40 AM, Vlado Handziski
<han...@tk...> wrote:
> It looks like there is a bug in src/nesc-compile related to the path of the
> deputy_stage2.h file. At least on my machine the /include subfolder in ncc
> is not created, and the header files are put in ncc, resulting in compile
> error:
>
> [hanjo@localhost Blink]$ make telosb safe
> mkdir -p build/telosb
>     compiling BlinkAppC to a telosb binary
> ncc -o build/telosb/main.exe -DSAFE_TINYOS -fnesc-deputy -fnesc-default-safe
> -fnesc-deputy-args='-I/home/hanjo/tos/tinyos-2.x-vanilla/tos/lib/safe/include
> --FLIDs --envmachine -DSAFE_TINYOS --nolib '
> /home/hanjo/tos/tinyos-2.x-vanilla/tos/lib/safe/msp430/fail.c  -Os -O
> -mdisable-hwmul -Wall -Wshadow -Wnesc-all -target=telosb
> -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22
> -DIDENT_PROGRAM_NAME=\"BlinkAppC\" -DIDENT_USER_ID=\"hanjo\"
> -DIDENT_HOSTNAME=\"localhost.local\" -DIDENT_USER_HASH=0x43fc9287L
> -DIDENT_UNIX_TIME=0x485a36c0L -DIDENT_UID_HASH=0x751fee7bL  BlinkAppC.nc -lm
> build/telosb/app.c:1:54: /usr/local/lib/ncc/include/deputy_stage2.h: No such
> file or directory

Ok, I've put a beta3 on sourceforge which fixes this problem (thanks
Vlado!). Two options now:
- we (Kevin ;-)) can make a beta3 debian package
- all beta2 users can do:
  sudo ln -s /usr/lib/ncc /usr/lib/ncc/include

David

Re: [nescc-devel] nesC 1.3.0 beta2

[David G. <dg...@gm...>]

On Thu, Jun 19, 2008 at 3:40 AM, Vlado Handziski
<han...@tk...> wrote:
> It looks like there is a bug in src/nesc-compile related to the path of the
> deputy_stage2.h file. At least on my machine the /include subfolder in ncc
> is not created, and the header files are put in ncc, resulting in compile
> error:
>
> [hanjo@localhost Blink]$ make telosb safe
> mkdir -p build/telosb
>     compiling BlinkAppC to a telosb binary
> ncc -o build/telosb/main.exe -DSAFE_TINYOS -fnesc-deputy -fnesc-default-safe
> -fnesc-deputy-args='-I/home/hanjo/tos/tinyos-2.x-vanilla/tos/lib/safe/include
> --FLIDs --envmachine -DSAFE_TINYOS --nolib '
> /home/hanjo/tos/tinyos-2.x-vanilla/tos/lib/safe/msp430/fail.c  -Os -O
> -mdisable-hwmul -Wall -Wshadow -Wnesc-all -target=telosb
> -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22
> -DIDENT_PROGRAM_NAME=\"BlinkAppC\" -DIDENT_USER_ID=\"hanjo\"
> -DIDENT_HOSTNAME=\"localhost.local\" -DIDENT_USER_HASH=0x43fc9287L
> -DIDENT_UNIX_TIME=0x485a36c0L -DIDENT_UID_HASH=0x751fee7bL  BlinkAppC.nc -lm
> build/telosb/app.c:1:54: /usr/local/lib/ncc/include/deputy_stage2.h: No such
> file or directory
>
> So either the include should be created or the path in nesc-compile should
> be changed:
>
>
> --- nesc-compile.old    2008-06-19 12:32:21.000000000 +0200
> +++ nesc-compile        2008-06-19 12:32:45.000000000 +0200
> @@ -119,7 +119,7 @@
>  # Deputy annotations
>  if($deputy) {
>      unshift @nesc_args, "-fnesc-include=deputy_stage1";
> -    unshift @nesc_args, "-fnesc-genprefix=#include
> \"$ENV{NCDIR}/include/deputy_stage2.h\"";
> +    unshift @nesc_args, "-fnesc-genprefix=#include
> \"$ENV{NCDIR}/deputy_stage2.h\"";
>  }
>  else {
>      unshift @nesc_args, "-fnesc-include=deputy_nodeputy";

You're right, and that's the right patch.

David