Re: Compressed patch to move make/custom/* to make/*

[Sebastian Huber]

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html


If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make

?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Sebastian Huber]

On 08/02/18 09:11, Sebastian Huber wrote:

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html


If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make

?



The corresponding ticket is:

https://devel.rtems.org/ticket/3285

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Why I could not find the file cpuopts.h in master

[talos]

Did anyone find this file? Thanks!___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Why I could not find the file cpuopts.h in master

[Gedare Bloom]

cpuopts.h is generated during the build process. You can find it in
your build tree after you make RTEMS.

On Thu, Feb 8, 2018 at 5:10 AM, talos <2486580...@qq.com> wrote:
> Did anyone find this file? Thanks!
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Gedare Bloom]

On Thu, Feb 8, 2018 at 4:05 AM, Sebastian Huber
 wrote:
> On 08/02/18 09:11, Sebastian Huber wrote:
>>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>>
>>> Hi
>>>
>>> The patch was quite large and rightly blocked from being sent to
>>> everyone (~900k). Compressed, it is only 63K
>>>
>>> This eliminates the custom directory and moves everything up
>>> one level.  No failures in the build as shown here.
>>>
>>> https://lists.rtems.org/pipermail/build/2018-February/000398.html
>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>> ?
>>
>
> The corresponding ticket is:
>
> https://devel.rtems.org/ticket/3285
>
+1

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ARM and PowerPC Shared Linkcmds Alignment Issue

[Sebastian Huber]

On 31/01/18 21:10, Joel Sherrill wrote:

Hi

I am debugging a paravirtualized BSP. On the ARM and PowerPC,
we want to use the linkcmds.share infrastructure but both use
ALIGN_WITH_INPUT for the first .data section.

For these BSPs, we need the .data to be on a 4K page boundary.


Why the .data section?

You can add an empty array with a 4KiB alignment and a section attribute 
for specific linker input sections.


If you want to place all read-write data on a 4KiB boundary, then use

bsp_section_rwbarrier_align = 4096;

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

tests using FP specifiers in prints

[Joel Sherrill]

Hi

Jennifer noticed that sp19 prints %g instead of numbers now that
we switched to printk for the tests.  I did a quick grep and found these:

testsuites$ grep -rl "%g" .
./samples/fileio/init.c
./samples/paranoia/paranoia.c
./sptests/sp19/first.c
./sptests/sp19/fptask.c
./sptests/sp19/fptest.h
./tmtests/tm26/fptest.h

Are fileio and paranoia using printf()?

Do we need to eliminate these uses of %g in sptests and tmtests?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Joel Sherrill]

On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/18 09:11, Sebastian Huber wrote:
>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>
>>> Hi
>>>
>>> The patch was quite large and rightly blocked from being sent to
>>> everyone (~900k). Compressed, it is only 63K
>>>
>>> This eliminates the custom directory and moves everything up
>>> one level.  No failures in the build as shown here.
>>>
>>> https://lists.rtems.org/pipermail/build/2018-February/000398.html
>>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>>
OK. I can pick at that but what does from testsuites this change to?

include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg

Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?

Is there a Makefile.am variable that really points to the top of the source
tree?

The other common pattern is

include $(RTEMS_ROOT)/make/custom/default.cfg

in all the BSP .cfg files? What will that need to be to work before and
after install?

RTEMS_ROOT is the build tree and later the install point. I don't
know how to make that one work.

Any thoughts?




> ?
>>
>>
> The corresponding ticket is:
>
> https://devel.rtems.org/ticket/3285


I thought I put that in the commit message


>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Sebastian Huber]

On 08/02/18 16:08, Joel Sherrill wrote:


On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber 
> wrote:


On 08/02/18 09:11, Sebastian Huber wrote:

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being
sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html



If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make


OK. I can pick at that but what does from testsuites this change to?

include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg

Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?

Is there a Makefile.am variable that really points to the top of the 
source tree?


The other common pattern is

include $(RTEMS_ROOT)/make/custom/default.cfg

in all the BSP .cfg files? What will that need to be to work before and
after install?

RTEMS_ROOT is the build tree and later the install point. I don't
know how to make that one work.

Any thoughts?


No user should be forced to touch its Makefiles only because we move 
some files in the RTEMS source tree from A to B. So, I think the install 
location should remain as is.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tests using FP specifiers in prints

[Sebastian Huber]

On 08/02/18 16:02, Joel Sherrill wrote:

Hi

Jennifer noticed that sp19 prints %g instead of numbers now that
we switched to printk for the tests.  I did a quick grep and found these:

testsuites$ grep -rl "%g" .
./samples/fileio/init.c
./samples/paranoia/paranoia.c
./sptests/sp19/first.c
./sptests/sp19/fptask.c
./sptests/sp19/fptest.h
./tmtests/tm26/fptest.h

Are fileio and paranoia using printf()?


They use:

testsuites/samples/pppd/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/samples/loopback/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/samples/paranoia/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/samples/hello/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/samples/capture/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/benchmarks/linpack/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/benchmarks/whetstone/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/benchmarks/dhrystone/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/libtests/mathl/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/libtests/mathf/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/libtests/complex/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/libtests/capture01/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/libtests/math/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/smptests/smpmigration01/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/smptests/smpopenmp01/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);
testsuites/sptests/spconsole01/init.c: 
rtems_print_printer_fprintf_putc(&rtems_test_printer);




Do we need to eliminate these uses of %g in sptests and tmtests?

--joel







___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Joel Sherrill]

On Thu, Feb 8, 2018 at 9:10 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/18 16:08, Joel Sherrill wrote:
>
>>
>> On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > ed-brains.de>> wrote:
>>
>> On 08/02/18 09:11, Sebastian Huber wrote:
>>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>
>> Hi
>>
>> The patch was quite large and rightly blocked from being
>> sent to
>> everyone (~900k). Compressed, it is only 63K
>>
>> This eliminates the custom directory and moves everything up
>> one level.  No failures in the build as shown here.
>>
>> https://lists.rtems.org/pipermail/build/2018-February/000398
>> .html
>> > 8.html>
>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>>
>> OK. I can pick at that but what does from testsuites this change to?
>>
>> include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
>>
>> Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?
>>
>> Is there a Makefile.am variable that really points to the top of the
>> source tree?
>>
>> The other common pattern is
>>
>> include $(RTEMS_ROOT)/make/custom/default.cfg
>>
>> in all the BSP .cfg files? What will that need to be to work before and
>> after install?
>>
>> RTEMS_ROOT is the build tree and later the install point. I don't
>> know how to make that one work.
>>
>> Any thoughts?
>>
>
> No user should be forced to touch its Makefiles only because we move some
> files in the RTEMS source tree from A to B. So, I think the install
> location should remain as is.


I agree but I think you missed my point. The use in testsuites can be fixed
to point
to the source tree.  But if I change the includes in the "custom" files, I
have concerns
that it may not be possible to make it work in both when building and
installed.

./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit.cfg:include
$(RTEMS_ROOT)/make/custom/altcycv.inc
./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit_smp.cfg:include
$(RTEMS_ROOT)/make/custom/altcycv.inc
./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv.inc:include
$(RTEMS_ROOT)/make/custom/default.cfg

I just grep'ed for RTEMS_ROOT and it appears that I need to change the
definition
of where it points. It is mostly used to point to the custom files but this
looks
problematic:

/c/src/Makefile.am:'RTEMS_BSP=@RTEMS_BSP@' 'RTEMS_ROOT=.' \
./c/src/configure.ac:RTEMS_ROOT=. make/${RTEMS_BSP}.cache

All the references in testsuites can be to top_srcdir. Easy to eliminate
RTEMS_ROOT
completely I think in there. But what should RTEMS_ROOT be set to in
c/src/configure.ac to make it work? What variable has the top of the source
tree?

I guess $(top_srcdir)/../..?

Thoughts?



>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: tests using FP specifiers in prints

[Joel Sherrill]

On Thu, Feb 8, 2018 at 9:13 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/18 16:02, Joel Sherrill wrote:
>
>> Hi
>>
>> Jennifer noticed that sp19 prints %g instead of numbers now that
>> we switched to printk for the tests.  I did a quick grep and found these:
>>
>> testsuites$ grep -rl "%g" .
>> ./samples/fileio/init.c
>> ./samples/paranoia/paranoia.c
>> ./sptests/sp19/first.c
>> ./sptests/sp19/fptask.c
>> ./sptests/sp19/fptest.h
>> ./tmtests/tm26/fptest.h
>>
>> Are fileio and paranoia using printf()?
>>
>
> They use:
>
> testsuites/samples/pppd/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/samples/loopback/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/samples/paranoia/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/samples/hello/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/samples/capture/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/benchmarks/linpack/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/benchmarks/whetstone/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/benchmarks/dhrystone/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/libtests/mathl/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/libtests/mathf/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/libtests/complex/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/libtests/capture01/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/libtests/math/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/smptests/smpmigration01/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/smptests/smpopenmp01/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
> testsuites/sptests/spconsole01/init.c: rtems_print_printer_fprintf_pu
> tc(&rtems_test_printer);
>


sp19 and tm26 are not in that list. What about them?


>
>
>> Do we need to eliminate these uses of %g in sptests and tmtests?
>>
>> --joel
>>
>>
>>
>>
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

[Chris Johns]

On 09/02/2018 02:22, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 9:10 AM, Sebastian Huber
>  >
> wrote:
> On 08/02/18 16:08, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber
>  
>  >> wrote:
> 
> On 08/02/18 09:11, Sebastian Huber wrote:
> 
> On 08/02/18 01:00, Joel Sherrill wrote:
> 
> Hi
> 
> The patch was quite large and rightly blocked from being
> sent to
> everyone (~900k). Compressed, it is only 63K
> 
> This eliminates the custom directory and moves everything 
> up
> one level.  No failures in the build as shown here.
> 
>
> https://lists.rtems.org/pipermail/build/2018-February/000398.html
> 
>
>  >
> 
> 
> If we move this stuff, then why not to
> 
> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
> 
> 
> OK. I can pick at that but what does from testsuites this change to?
> 
> include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> 
> Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?
> 
> Is there a Makefile.am variable that really points to the top of the
> source tree?
> 
> The other common pattern is
> 
> include $(RTEMS_ROOT)/make/custom/default.cfg
> 
> in all the BSP .cfg files? What will that need to be to work before 
> and
> after install?
> 
> RTEMS_ROOT is the build tree and later the install point. I don't
> know how to make that one work.
> 
> Any thoughts?
> 
> 
> No user should be forced to touch its Makefiles only because we move some
> files in the RTEMS source tree from A to B. So, I think the install 
> location
> should remain as is.
> 
> 
> I agree but I think you missed my point. The use in testsuites can be fixed 
> to point
> to the source tree.  But if I change the includes in the "custom" files, I 
> have
> concerns
> that it may not be possible to make it work in both when building and 
> installed. 
> 

Exporting anything internal to users is always going to present a risk, we have
known and acknowledged this for years. It has been part of the reason we have
avoided making changes in the build system however my attitude is changing or
has changed, ie removing preinstall.

Long term I cannot see how we can sustain this interface and that means we need
to determine when it goes? I am more than happy to be proved wrong. It is only
fair to those who use these installed files they get suitable warning and we
need to figure out what we provide to replace it.

Building new applications and products based on this type of application build
framework with RTEMS 5 should be discouraged. We are looking to increase the
release frequency and this will only shorten the life span for these files.

> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit_smp.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv.inc:include
> $(RTEMS_ROOT)/make/custom/default.cfg
> 
> I just grep'ed for RTEMS_ROOT and it appears that I need to change the 
> definition
> of where it points. It is mostly used to point to the custom files but this 
> looks 
> problematic:
> 
> /c/src/Makefile.am:'RTEMS_BSP=@RTEMS_BSP@' 'RTEMS_ROOT=.' \
> ./c/src/configure.ac:RTEMS_ROOT=. make/${RTEMS_BSP}.cache
> 
> All the references in testsuites can be to top_srcdir. Easy to eliminate 
> RTEMS_ROOT
> completely I think in there. But what should RTEMS_ROOT be set to in
> c/src/configure.ac  to make it work? What variable has 
> the
> top of the source tree?
> 
> I guess $(top_srcdir)/../..?
> > Thoughts?
> 

You are entering a swamp made of "top.*" labelled quick sand as I found out in
the preinstall removal. Top is relative and is implemented as a hack I refrain
from fully explaining so I do not offend. There are a number of "tops" in the
tree and then there are lists of ".."s to go up and down and that number depends
on the relative point to the "top" you are under. There are no consistent rules
across the source and it depends on a mix of different .m4 pieces with the same
macro and files names in different aclocal directories that are effected by the
command line options to the nested configure calls that is c

Re: tests using FP specifiers in prints

[Sebastian Huber]

On 08/02/18 16:45, Joel Sherrill wrote:
sp19 and tm26 are not in that list. What about them? 


They should be fixed now.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel