[PATCH] wscript: fix default version from 4.12 to 5

[Gedare Bloom]

---
 wscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wscript b/wscript
index f3c8304..f32fb8d 100644
--- a/wscript
+++ b/wscript
@@ -17,7 +17,7 @@
 # to build for more than BSP at a time.
 #
 
-rtems_version = "4.12"
+rtems_version = "5"
 try:
 import rtems_waf.rtems as rtems
 except:
-- 
2.7.4

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

Re: no-preinstall: Ready for final review

[Gedare Bloom]

On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
 wrote:
> Hello,
>
> the no-preinstall branch is now in a good shape.
>
> https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
>
> Please review this work. The next step would be to squash all commits on
> this branch, write a proper commit message and push it to the master.
>
Hello Sebastian,

I checked it out, built erc32, ran erc32 from the build, installed the
bsp, and ran it again fine using rtems-tools/tester.

However, when I try to waf-configure examples-v2, I get a problem that
rtems/score/cpuopts.h is not found. When I look in my installed tree,
I do not find the file:

$ find /opt/rtems-5 -name cpuopts.h
$ find /opt/rtems-5 -name include
./sparc-rtems5/erc32/lib/include

I do see it in my build tree:
~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h

Relatedly, I don't see the bspopts.h file in the installed tree
either. I do see it in the build tree, in a different location from
the rest of the includes:
~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h

I also took a quick look through the commits, and I have a small nit.
Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
and "header.am"?

-Gedare

> --
> 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: no-preinstall: Ready for final review

[Sebastian Huber]

I fixed the cpuopts.h problem two minutes ago.

- Gedare Bloom  schrieb:
> On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
>  wrote:
> > Hello,
> >
> > the no-preinstall branch is now in a good shape.
> >
> > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
> >
> > Please review this work. The next step would be to squash all commits on
> > this branch, write a proper commit message and push it to the master.
> >
> Hello Sebastian,
> 
> I checked it out, built erc32, ran erc32 from the build, installed the
> bsp, and ran it again fine using rtems-tools/tester.
> 
> However, when I try to waf-configure examples-v2, I get a problem that
> rtems/score/cpuopts.h is not found. When I look in my installed tree,
> I do not find the file:
> 
> $ find /opt/rtems-5 -name cpuopts.h
> $ find /opt/rtems-5 -name include
> ./sparc-rtems5/erc32/lib/include
> 
> I do see it in my build tree:
> ~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
> ./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h
> 
> Relatedly, I don't see the bspopts.h file in the installed tree
> either. I do see it in the build tree, in a different location from
> the rest of the includes:
> ~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h
> 
> I also took a quick look through the commits, and I have a small nit.
> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
> and "header.am"?
> 
> -Gedare
> 
> > --
> > 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

-- 
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.huber at 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: no-preinstall: Ready for final review

[Gedare Bloom]

On Thu, Jan 18, 2018 at 10:20 AM, Sebastian Huber
 wrote:
> I fixed the cpuopts.h problem two minutes ago.
>
Thanks.

I just noticed that actually when I run tester on the installed tree I
get a lot of timeouts. I'm not sure if this is my host problem.

> - Gedare Bloom  schrieb:
>> On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
>>  wrote:
>> > Hello,
>> >
>> > the no-preinstall branch is now in a good shape.
>> >
>> > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
>> >
>> > Please review this work. The next step would be to squash all commits on
>> > this branch, write a proper commit message and push it to the master.
>> >
>> Hello Sebastian,
>>
>> I checked it out, built erc32, ran erc32 from the build, installed the
>> bsp, and ran it again fine using rtems-tools/tester.
>>
>> However, when I try to waf-configure examples-v2, I get a problem that
>> rtems/score/cpuopts.h is not found. When I look in my installed tree,
>> I do not find the file:
>>
>> $ find /opt/rtems-5 -name cpuopts.h
>> $ find /opt/rtems-5 -name include
>> ./sparc-rtems5/erc32/lib/include
>>
>> I do see it in my build tree:
>> ~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
>> ./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h
>>
>> Relatedly, I don't see the bspopts.h file in the installed tree
>> either. I do see it in the build tree, in a different location from
>> the rest of the includes:
>> ~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
>> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h
>>
>> I also took a quick look through the commits, and I have a small nit.
>> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
>> and "header.am"?
>>
>> -Gedare
>>
>> > --
>> > 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
>
> --
> 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.huber at 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: no-preinstall: Ready for final review

[Gedare Bloom]

On Thu, Jan 18, 2018 at 10:34 AM, Gedare Bloom  wrote:
> On Thu, Jan 18, 2018 at 10:20 AM, Sebastian Huber
>  wrote:
>> I fixed the cpuopts.h problem two minutes ago.
>>
> Thanks.
>
> I just noticed that actually when I run tester on the installed tree I
> get a lot of timeouts. I'm not sure if this is my host problem.
>
I have a new problem:

build/config.log:err:
/home/gedare/development/rtems/5/lib/gcc/sparc-rtems5/7.2.0/../../../../sparc-rtems5/bin/ld:
cannot open linker script file linkcmds.base: No such file or
directory

That file does not appear to leave the source tree.
gedare:~/work/rtems/builds/b-erc32-5$ find . -name linkcmds.base
gedare::~/work/rtems/builds/b-erc32-5$ find . -name linkcmds
./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/linkcmds


>> - Gedare Bloom  schrieb:
>>> On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
>>>  wrote:
>>> > Hello,
>>> >
>>> > the no-preinstall branch is now in a good shape.
>>> >
>>> > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
>>> >
>>> > Please review this work. The next step would be to squash all commits on
>>> > this branch, write a proper commit message and push it to the master.
>>> >
>>> Hello Sebastian,
>>>
>>> I checked it out, built erc32, ran erc32 from the build, installed the
>>> bsp, and ran it again fine using rtems-tools/tester.
>>>
>>> However, when I try to waf-configure examples-v2, I get a problem that
>>> rtems/score/cpuopts.h is not found. When I look in my installed tree,
>>> I do not find the file:
>>>
>>> $ find /opt/rtems-5 -name cpuopts.h
>>> $ find /opt/rtems-5 -name include
>>> ./sparc-rtems5/erc32/lib/include
>>>
>>> I do see it in my build tree:
>>> ~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
>>> ./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h
>>>
>>> Relatedly, I don't see the bspopts.h file in the installed tree
>>> either. I do see it in the build tree, in a different location from
>>> the rest of the includes:
>>> ~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
>>> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h
>>>
>>> I also took a quick look through the commits, and I have a small nit.
>>> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
>>> and "header.am"?
>>>
>>> -Gedare
>>>
>>> > --
>>> > 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
>>
>> --
>> 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.huber at 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: no-preinstall: Ready for final review

[Sebastian Huber]

Is this after installation or during the BSP build?

- Am 18. Jan 2018 um 17:19 schrieb Gedare Bloom ged...@rtems.org:

> On Thu, Jan 18, 2018 at 10:34 AM, Gedare Bloom  wrote:
>> On Thu, Jan 18, 2018 at 10:20 AM, Sebastian Huber
>>  wrote:
>>> I fixed the cpuopts.h problem two minutes ago.
>>>
>> Thanks.
>>
>> I just noticed that actually when I run tester on the installed tree I
>> get a lot of timeouts. I'm not sure if this is my host problem.
>>
> I have a new problem:
> 
> build/config.log:err:
> /home/gedare/development/rtems/5/lib/gcc/sparc-rtems5/7.2.0/../../../../sparc-rtems5/bin/ld:
> cannot open linker script file linkcmds.base: No such file or
> directory
> 
> That file does not appear to leave the source tree.
> gedare:~/work/rtems/builds/b-erc32-5$ find . -name linkcmds.base
> gedare::~/work/rtems/builds/b-erc32-5$ find . -name linkcmds
> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/linkcmds
> 
> 
>>> - Gedare Bloom  schrieb:
 On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
  wrote:
 > Hello,
 >
 > the no-preinstall branch is now in a good shape.
 >
 > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
 >
 > Please review this work. The next step would be to squash all commits on
 > this branch, write a proper commit message and push it to the master.
 >
 Hello Sebastian,

 I checked it out, built erc32, ran erc32 from the build, installed the
 bsp, and ran it again fine using rtems-tools/tester.

 However, when I try to waf-configure examples-v2, I get a problem that
 rtems/score/cpuopts.h is not found. When I look in my installed tree,
 I do not find the file:

 $ find /opt/rtems-5 -name cpuopts.h
 $ find /opt/rtems-5 -name include
 ./sparc-rtems5/erc32/lib/include

 I do see it in my build tree:
 ~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
 ./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h

 Relatedly, I don't see the bspopts.h file in the installed tree
 either. I do see it in the build tree, in a different location from
 the rest of the includes:
 ~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
 ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h

 I also took a quick look through the commits, and I have a small nit.
 Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
 and "header.am"?

 -Gedare

 > --
 > 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
>>>
>>> --
>>> 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.huber at 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: no-preinstall: Ready for final review

[Sebastian Huber]

v1 of the commit message:

Remove make preinstall

A speciality of the RTEMS build system was the make preinstall step.  It copied
header files from arbitrary locations into the build tree.  The header files
were included via the -Bsome/build/tree/path GCC command line option.

This has at least five problems:

* The make preinstall step itself needs time and disk space.

* Errors in header files show up in the build tree copy.  This makes it hard
  for editors to open the right file to fix the error.

* There is no clear relationship between source and build tree header files.
  This makes an audit of the build process difficult.

* The visibility of all header files in the build tree makes it difficult to
  enforce API barriers.  For example it is discouraged to use BSP-specifics in
  the cpukit.

* An introduction of a new build system is difficult.

This patch removes the make preinstall step.   All installed header files are
moved to dedicated include directories in the source tree.  Let @RTEMS_CPU@ be
the target architecture, e.g. arm, powerpc, sparc, etc.  Let
@RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g. erc32, imx, qoriq,
etc.

The new cpukit include directories are:

* cpukit/include

* cpukit/score/cpu/@RTEMS_CPU@/include

* cpukit/libnetworking

The new BSP include directories are:

* bsps/include

* bsps/@RTEMS_CPU@/include

* bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include

There are build tree include directories for generated files.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: no-preinstall: Ready for final review

[Gedare Bloom]

After installation. The BSP builds fine

On Thu, Jan 18, 2018 at 11:33 AM, Sebastian Huber
 wrote:
> Is this after installation or during the BSP build?
>
> - Am 18. Jan 2018 um 17:19 schrieb Gedare Bloom ged...@rtems.org:
>
>> On Thu, Jan 18, 2018 at 10:34 AM, Gedare Bloom  wrote:
>>> On Thu, Jan 18, 2018 at 10:20 AM, Sebastian Huber
>>>  wrote:
 I fixed the cpuopts.h problem two minutes ago.

>>> Thanks.
>>>
>>> I just noticed that actually when I run tester on the installed tree I
>>> get a lot of timeouts. I'm not sure if this is my host problem.
>>>
>> I have a new problem:
>>
>> build/config.log:err:
>> /home/gedare/development/rtems/5/lib/gcc/sparc-rtems5/7.2.0/../../../../sparc-rtems5/bin/ld:
>> cannot open linker script file linkcmds.base: No such file or
>> directory
>>
>> That file does not appear to leave the source tree.
>> gedare:~/work/rtems/builds/b-erc32-5$ find . -name linkcmds.base
>> gedare::~/work/rtems/builds/b-erc32-5$ find . -name linkcmds
>> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/linkcmds
>>
>>
 - Gedare Bloom  schrieb:
> On Wed, Jan 17, 2018 at 2:24 AM, Sebastian Huber
>  wrote:
> > Hello,
> >
> > the no-preinstall branch is now in a good shape.
> >
> > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
> >
> > Please review this work. The next step would be to squash all commits on
> > this branch, write a proper commit message and push it to the master.
> >
> Hello Sebastian,
>
> I checked it out, built erc32, ran erc32 from the build, installed the
> bsp, and ran it again fine using rtems-tools/tester.
>
> However, when I try to waf-configure examples-v2, I get a problem that
> rtems/score/cpuopts.h is not found. When I look in my installed tree,
> I do not find the file:
>
> $ find /opt/rtems-5 -name cpuopts.h
> $ find /opt/rtems-5 -name include
> ./sparc-rtems5/erc32/lib/include
>
> I do see it in my build tree:
> ~/work/rtems/builds/b-erc32-5$ find . -name cpuopts.h
> ./sparc-rtems5/c/erc32/include/rtems/score/cpuopts.h
>
> Relatedly, I don't see the bspopts.h file in the installed tree
> either. I do see it in the build tree, in a different location from
> the rest of the includes:
> ~/work/rtems/builds/b-erc32-5$ find . -name bspopts.h
> ./sparc-rtems5/c/erc32/lib/libbsp/sparc/erc32/include/bspopts.h
>
> I also took a quick look through the commits, and I have a small nit.
> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
> and "header.am"?
>
> -Gedare
>
> > --
> > 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

 --
 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.huber at 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: no-preinstall: Ready for final review

[Sebastian Huber]

- Am 18. Jan 2018 um 16:06 schrieb Gedare Bloom ged...@rtems.org:

[...]
> I also took a quick look through the commits, and I have a small nit.
> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
> and "header.am"?

I want to add this stuff to the bootstrap script as a -p replacement.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: no-preinstall: Ready for final review

[Gedare Bloom]

On Thu, Jan 18, 2018 at 11:36 AM, Sebastian Huber
 wrote:
>
>
> - Am 18. Jan 2018 um 16:06 schrieb Gedare Bloom ged...@rtems.org:
>
> [...]
>> I also took a quick look through the commits, and I have a small nit.
>> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
>> and "header.am"?
>
> I want to add this stuff to the bootstrap script as a -p replacement.

That's fine with me. I would still prefer the generated file be named
headers.am to reflect the purpose of defining the (multiple) include
headers.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: no-preinstall: Ready for final review

[Sebastian Huber]

- Gedare Bloom  schrieb:
> On Thu, Jan 18, 2018 at 11:36 AM, Sebastian Huber
>  wrote:
> >
> >
> > - Am 18. Jan 2018 um 16:06 schrieb Gedare Bloom ged...@rtems.org:
> >
> > [...]
> >> I also took a quick look through the commits, and I have a small nit.
> >> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
> >> and "header.am"?
> >
> > I want to add this stuff to the bootstrap script as a -p replacement.
> 
> That's fine with me. I would still prefer the generated file be named
> headers.am to reflect the purpose of defining the (multiple) include
> headers.

Ok, this is easy to change.

-- 
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.huber at 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: [PATCH] gcc: Reference GNU's FTP site for all GCC parts.

[Joel Sherrill]

On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns  wrote:

> On 18/1/18 11:01 am, Joel Sherrill wrote:
> > On Wed, Jan 17, 2018 at 5:21 PM, Chris Johns  > > wrote:
> >
> > On 18/1/18 9:30 am, Joel Sherrill wrote:
> > > Why can't we change it to here for 4.10?
> > >
> > > http://www.multiprecision.org/downloads/mpc-0.8.1.tar.gz
> > 
> > >
> >
> > We could however it leaves us open to the same issue that started us
> looking at
> > this problem and there is a push to make 4.10 a long term supported
> release. If
> > the home site changes it breaks the release branch.
> >
> > With RPM tool's was the host's (distros) shared library version
> being used? I
> > seem to remember the view at the time was host's version was
> preferred cause
> > distro maintainers always know best. If this is the case which
> version is being
> > used?
> >
> > I see the alternatives as:
> >
> >  1. Investigate the role MPC plays and what effect it has on the
> generated code.
> >  2. Make MPC a special and hope the web site stays the same.
> >
> > No matter what path we take we need to make sure we are happy with
> the generated
> > code for the RSB tools to make a release. How do we do this?
> >
> >  a. Assume it is OK if the tests results match.
> >  b. Check the generated code.
> >
> > Checking the generated code requires a build of the 4.10.2 kernel
> with the RPM
> > tools. If this path is taken I need a tarball of the installed only
> 4.10.2
> > kernel built with RPM tools for selected archs. I can then check the
> generated
> > code. I have no ability to install and run the RPM tools.
> >
> >
> > I actually wonder how hard it would be to do this. I suspect you need
> > something like CentOS 6 or 7 and compatibility libraries. If that's
> sufficient
> > and possible.
>
> What about using:
>
>  rtems-4.10-sparc-rtems4.10-newlib-1.18.0-34.el6.noarch.rpm
>  rtems-4.10-sparc-rtems4.10-gcc-libstdc++-4.4.7-6.el6.noarch.rpm
>  rtems-4.10-sparc-rtems4.10-gcc-libgcc-4.4.7-6.el6.noarch.rpm
>
> from:
>
>  https://ftp.rtems.org/pub/rtems/archive/rpms/linux/4.10/centos/6/i386/
>
> ?
>
> We could check some of the code in libgcc and newlib libraries built with
> the
> RPM executables at the time?
>

We could but I think you missed my point that the MPC used was the one
installed on the host -- we didn't package an MPC.


>
> > A quick check shows the CentOS 6 RPM for mpc is 0.8-3 so 0.8 with
> patches.
> > That's more suspect to me than a base use of something newer. It doesn't
> match
> > anything any other distribution is going to have. And it used gcc 4.4.x
> as a host
> > compiler. 4.4.7 was the RPM I found on a random mirror.
>
> Yes it is a mess and the more you look the harder it gets to quantify what
> is
> actually being used.
>
> Is the RTEMS MPC RPM installed and if installed is it used?
>

There was no RTEMS MPC RPM. So if you built on RHEL 6 you got a different
host MPC than if on FreeBSD.


>
> > (1) is what we have done in the past. But we decided that depending on
> the
> > host for mpc and mpfr was a risk.
>
> Yes and why the RSB is very specific about how it is built and what is
> built. It
> is just over 6 years since 4.11.2 was released with RPM tools and the RSB
> puts
> us in an excellent position to create a long term supported release.
>

This is a good thing and why I think we might has well just suck up the
side-effects and pick a version for the RSB to use. It was an unknown
variable
for the tools built for the RPM. If you remember, there was a complex
environment which mimicked each host to cross build. There would end
up potentially being a different MPC version on each host and version.
For sure, RHEL 5, 6, and 7 have different versions.

I say we just have to pick one and move on.


>
> I have built the 4.10 branch tools on FreeBSD 11.1, Windows 10 64bit, MacOS
> (High Sierra) and you and Gedare have built them on Linux and I think this
> is
> pretty neat. The credit for this must go to all of the standardization
> work in
> gcc and parts and various hosts such as FreeBSD, Linux, MacOS and Cygwin.
>

+1 I also built on FreeBSD.

>
> >
> > I would lean to picking something -- anything-- for mpc and just moving
> > forward.
> >
>
> I tend to agree but we need to do some checking at the RSB level.
>

Yep. We can either pick what was used on RHEL 6 which is likely the
most used host for the RPMs or just move to the 1.x which is on the GNU
ftp site.

I lean to using the one on the GNU ftp site just so we have a permanent
host to fetch from.

This is unfortunately just a side-effect of the more rigorous RSB.

To quote Rush: If you choose not to decide, you still have made a choice.

Benevolent dictator says use the one from GNU ftp. :)

Justification: permanent URL. Nothing stronger.

--joel


>
> Chris
>
___

Re: no-preinstall: Ready for final review

[Chris Johns]

On 19/1/18 3:35 am, Sebastian Huber wrote:
> v1 of the commit message:

Looks good.

Best to limit the number of problems with preinstalling to just 5 :)

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

Re: no-preinstall: Ready for final review

[Chris Johns]

On 19/1/18 3:37 am, Gedare Bloom wrote:
> On Thu, Jan 18, 2018 at 11:36 AM, Sebastian Huber
>  wrote:
>>
>>
>> - Am 18. Jan 2018 um 16:06 schrieb Gedare Bloom ged...@rtems.org:
>>
>> [...]
>>> I also took a quick look through the commits, and I have a small nit.
>>> Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
>>> and "header.am"?
>>
>> I want to add this stuff to the bootstrap script as a -p replacement.
> 
> That's fine with me. I would still prefer the generated file be named
> headers.am to reflect the purpose of defining the (multiple) include
> headers.

I do not think we should do this. I would prefer any addition is done by hand to
avoid picking up any header sitting in a developers tree. The initial bulk
injection should be a one off and after that API additions need consideration.

I would prefer `bootstrap -p` becomes a nop.

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

Re: no-preinstall: Ready for final review

[Gedare Bloom]

On Thu, Jan 18, 2018 at 3:34 PM, Chris Johns  wrote:
> On 19/1/18 3:37 am, Gedare Bloom wrote:
>> On Thu, Jan 18, 2018 at 11:36 AM, Sebastian Huber
>>  wrote:
>>>
>>>
>>> - Am 18. Jan 2018 um 16:06 schrieb Gedare Bloom ged...@rtems.org:
>>>
>>> [...]
 I also took a quick look through the commits, and I have a small nit.
 Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
 and "header.am"?
>>>
>>> I want to add this stuff to the bootstrap script as a -p replacement.
>>
>> That's fine with me. I would still prefer the generated file be named
>> headers.am to reflect the purpose of defining the (multiple) include
>> headers.
>
> I do not think we should do this. I would prefer any addition is done by hand 
> to
> avoid picking up any header sitting in a developers tree. The initial bulk
> injection should be a one off and after that API additions need consideration.
>
That's fair too. It should not be such a common case to add to the
headers.am files. One thing though, the file should have a comment
injected at the top to note that it is a generated file, not to edit
it (and how to regenerate it).

> I would prefer `bootstrap -p` becomes a nop.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] gcc: Reference GNU's FTP site for all GCC parts.

[Chris Johns]

On 19/1/18 4:48 am, Joel Sherrill wrote:
> 
> 
> On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns  > wrote:
> 
> On 18/1/18 11:01 am, Joel Sherrill wrote:
> > On Wed, Jan 17, 2018 at 5:21 PM, Chris Johns  
> > >> wrote:
> >
> >     On 18/1/18 9:30 am, Joel Sherrill wrote:
> >     > Why can't we change it to here for 4.10?
> >     >
> >     > http://www.multiprecision.org/downloads/mpc-0.8.1.tar.gz
> 
> >      >
> >     >
> >
> >     We could however it leaves us open to the same issue that started us
> looking at
> >     this problem and there is a push to make 4.10 a long term supported
> release. If
> >     the home site changes it breaks the release branch.
> >
> >     With RPM tool's was the host's (distros) shared library version 
> being
> used? I
> >     seem to remember the view at the time was host's version was 
> preferred
> cause
> >     distro maintainers always know best. If this is the case which 
> version
> is being
> >     used?
> >
> >     I see the alternatives as:
> >
> >      1. Investigate the role MPC plays and what effect it has on the
> generated code.
> >      2. Make MPC a special and hope the web site stays the same.
> >
> >     No matter what path we take we need to make sure we are happy with 
> the
> generated
> >     code for the RSB tools to make a release. How do we do this?
> >
> >      a. Assume it is OK if the tests results match.
> >      b. Check the generated code.
> >
> >     Checking the generated code requires a build of the 4.10.2 kernel 
> with
> the RPM
> >     tools. If this path is taken I need a tarball of the installed only 
> 4.10.2
> >     kernel built with RPM tools for selected archs. I can then check the
> generated
> >     code. I have no ability to install and run the RPM tools.
> >
> >
> > I actually wonder how hard it would be to do this. I suspect you need 
> > something like CentOS 6 or 7 and compatibility libraries. If that's 
> sufficient
> > and possible.
> 
> What about using:
> 
>  rtems-4.10-sparc-rtems4.10-newlib-1.18.0-34.el6.noarch.rpm
>  rtems-4.10-sparc-rtems4.10-gcc-libstdc++-4.4.7-6.el6.noarch.rpm
>  rtems-4.10-sparc-rtems4.10-gcc-libgcc-4.4.7-6.el6.noarch.rpm
> 
> from:
> 
>  https://ftp.rtems.org/pub/rtems/archive/rpms/linux/4.10/centos/6/i386/
> 
> 
> ?
> 
> We could check some of the code in libgcc and newlib libraries built with 
> the
> RPM executables at the time?
> 
> 
> We could but I think you missed my point that the MPC used was the one
> installed on the host -- we didn't package an MPC.
>  

Yes I did miss this.

> 
> 
> > A quick check shows the CentOS 6 RPM for mpc is 0.8-3 so 0.8 with 
> patches.
> > That's more suspect to me than a base use of something newer. It 
> doesn't match
> > anything any other distribution is going to have. And it used gcc 4.4.x 
> as a host
> > compiler. 4.4.7 was the RPM I found on a random mirror.
> 
> Yes it is a mess and the more you look the harder it gets to quantify 
> what is
> actually being used.
> 
> Is the RTEMS MPC RPM installed and if installed is it used?
> 
> 
> There was no RTEMS MPC RPM. So if you built on RHEL 6 you got a different
> host MPC than if on FreeBSD. 
>  

Yes I did not know this.

> 
> 
> > (1) is what we have done in the past. But we decided that depending on 
> the
> > host for mpc and mpfr was a risk.
> 
> Yes and why the RSB is very specific about how it is built and what is 
> built. It
> is just over 6 years since 4.11.2 was released with RPM tools and the RSB 
> puts
> us in an excellent position to create a long term supported release.
> 
> 
> This is a good thing and why I think we might has well just suck up the
> side-effects and pick a version for the RSB to use. It was an unknown variable
> for the tools built for the RPM. If you remember, there was a complex
> environment which mimicked each host to cross build. There would end
> up potentially being a different MPC version on each host and version.
> For sure, RHEL 5, 6, and 7 have different versions.
> 
> I say we just have to pick one and move on. 
>  

I selected 1.0.3 because it is used on RTEMS 5 so we will have the same version
on 4.10, 4.11 and 5.

> 
> 
> I have built the 4.10 branch tools on FreeBSD 11.1, Windows 10 64bit, 
> MacOS
> (High Sierra) and you and Gedare have built them on Linux and I think 
> this is
> pretty neat. The credit for this m

Re: [PATCH] rtems: Remove unused configuration files.

[Sebastian Huber]

The RSB policy with respect to configuration files is not clear to me. I 
thought these are read-only files that will be never removed? If you 
want to keep only the files used by the build sets, then why do they 
have file names with a version included?


Are branches in the RSB really practical? Each time something changes 
you have to back port it throughout the branches. When you build the 
tools you have to specify the version. So, what is the benefit of the 
branches?


--
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: no-preinstall: Ready for final review

[Sebastian Huber]

On 18/01/18 21:57, Gedare Bloom wrote:

On Thu, Jan 18, 2018 at 3:34 PM, Chris Johns  wrote:

On 19/1/18 3:37 am, Gedare Bloom wrote:

On Thu, Jan 18, 2018 at 11:36 AM, Sebastian Huber
  wrote:

- Am 18. Jan 2018 um 16:06 schrieb Gedare bloomged...@rtems.org:

[...]

I also took a quick look through the commits, and I have a small nit.
Might I suggest "headers.sh" and "headers.am" instead of "header.sh"
and "header.am"?

I want to add this stuff to the bootstrap script as a -p replacement.

That's fine with me. I would still prefer the generated file be named
headers.am to reflect the purpose of defining the (multiple) include
headers.

I do not think we should do this. I would prefer any addition is done by hand to
avoid picking up any header sitting in a developers tree. The initial bulk
injection should be a one off and after that API additions need consideration.


That's fair too. It should not be such a common case to add to the
headers.am files. One thing though, the file should have a comment
injected at the top to note that it is a generated file, not to edit
it (and how to regenerate it).



I added this comment to the headers.am:

## This file was generated by "./boostrap -H".

I moved the header.sh to bootstrap via the new -H option. The headers.am 
should be maintained by "./bootstrap -H". This ensures that the 
directory tree and the build system is in synchronization. Header file 
changes in BSPs are quite common. The workflow is like this:


$ touch bsps/sparc/erc32/include/bsp/foobar.h
$ ./bootstrap -H
Files headers.am.new and bsps/sparc/erc32/include/../headers.am differ
$ git status
On branch no-preinstall
Your branch is up-to-date with 'sh/no-preinstall'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

    modified:   bsps/sparc/erc32/headers.am

Untracked files:
  (use "git add ..." to include in what will be committed)

    bsps/sparc/erc32/include/bsp/foobar.h

no changes added to commit (use "git add" and/or "git commit -a")

Changes in headers.am are part of the patch set and can be reviewed easily.

--
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

RTEMS Tester and Log Files

[Sebastian Huber]

Hello,

the RTEMS Tester works quite well if it can run the tests step by step. 
I have a board were I can run reliably all tests at once with a custom 
script. I cannot run tests individually due to an instability in the 
debug support. This produces a large text file with the test output of 
all tests. Is there an option to simply feed this file to the rtems-test 
program and generate the report (optionally send it via e-mail)?


--
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

no-preinstall: Architecture-specific header files

[Sebastian Huber]

Hello,

the architecture-specific header files are currently in:

cpukit/score/cpu/@RTEMS_CPU@

For example:

cpukit/score/cpu/sparc/rtems/score/cpu.h

The new include directory for architecture-specific header files after 
the preinstall removal is:


cpukit/score/cpu/@RTEMS_CPU@/include

For example:

cpukit/score/cpu/sparc/include/rtems/score/cpu.h

There are two problems with this.

1. It introduces yet another sub-directory and makes the path longer.

2. It moves header files which are in this place since 1999. Using 
cpukit/score/cpu/@RTEMS_CPU@ as the include directory would avoid this.


This should be the last time we move header files around. It is very 
easy to move include directories in the no-preinstall branch.


Other options for architecture-specific header files are:

cpukit/score/cpu/@RTEMS_CPU@

cpukit/@RTEMS_CPU@/include

cpukit/arch/@RTEMS_CPU@/include

cpukit/cpu/@RTEMS_CPU@/include

cpukit/include/@RTEMS_CPU@

arch/@RTEMS_CPU@/include

include/@RTEMS_CPU@

The general include files are now in:

cpukit/include

Another option would be:

include

What do you think?

--
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