On 06/02/15 08:03, Amar Takhar wrote:
This email covers a brief overview of how to build the branch and some details.
It handy for 'trying it out' without getting too far into the details.
Thanks for your great work in the background.
Here is the timing for the build at the moment:
verm@pe
On 2015-02-08 18:34 +1100, Chris Johns wrote:
> On 6/02/2015 6:03 pm, Amar Takhar wrote:
> >
> > verm@peach# waf -j 14 --enable-tests
> > 'build' finished successfully (13.414s)
> >
> >note: the above is 881 targets.
> >
> I am not sure if this is the total number of tests. I thought it was
On 2015-02-08 09:40 +0100, Sebastian Huber wrote:
> One issue I found is that the test are not re-built in case the
> librtemscpu.a changes, e.g.
>
> sh@linux-p471:~/git-rtems-waf (waf) > touch
> ./build/sparc/sis/cpukit/librtemscpu.a
To clarify, you cannot make a change in the ./build/ directo
On 2015-02-08 09:40 +0100, Sebastian Huber wrote:
> Thanks for your great work in the background.
Thanks and you're welcome!
> I tested it on a five year old low budget laptop with an up to date
> openSUSE and it worked out of the box.
>
> I updated the timing page (2m with waf and 14m with t
On 08/02/15 15:05, Amar Takhar wrote:
On 2015-02-08 09:40 +0100, Sebastian Huber wrote:
One issue I found is that the test are not re-built in case the
librtemscpu.a changes, e.g.
sh@linux-p471:~/git-rtems-waf (waf) > touch
./build/sparc/sis/cpukit/librtemscpu.a
To clarify, you cannot make a c
On 2015-02-08 16:07 +0100, Sebastian Huber wrote:
> Yes, this works fine. If I change e.g. threaddispatch.c then all tests
> get re-linked. Very nice.
Great.
> What doesn't get noticed is the change of a C library header file, e.g.
> . This worked before due to the automatically generated
> d
