date:20181021

RFC: Value of New Section on Tools Build Time Expectations

2018-10-21 Thread Joel Sherrill

Hi

I am in the middle of reconfiguring my old (~2013 i7) laptop as an email
and remote workstation for home. Between helping students and doing two
Kick Starts in the past 6 weeks, VM configuration, disk space expectations,
and time required to build the tools seem to be a topic that needs to be
addressed. Under-configured VMs don't finish building or take a LONG time.

I am proposing that I gather performance and configuraton notes for
building SPARC tools after downloading source on a few configurations:

+ Laptop 2013 i7: Centos on VM
+ Laptop 2013 i7: MSYS2
+ Laptop 2013 i7: Cygwin
+ Laptop 2017 i7: Same three
+ 8 core Xeon Centos native
+ 12 core i7 Fedora native

One the 2017 7th generation i7, differences in VM configuration can result
in the build time for sparc tools almost tripling.

Does this sound useful or confusing? I know it is potentially somewhat
volatile information. But my old 3rd generation i7 CPU benchmark results
are comparable to an i5 that is much newer. Plus my old i7 has an SSD which
many newer i3/i5 laptops do not.

Feedback appreciated.

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

Re: RFC: Value of New Section on Tools Build Time Expectations

2018-10-21 Thread Christian Mauderer

Am 21.10.18 um 19:07 schrieb Joel Sherrill:
> Hi
> 
> I am in the middle of reconfiguring my old (~2013 i7) laptop as an email
> and remote workstation for home. Between helping students and doing two
> Kick Starts in the past 6 weeks, VM configuration, disk space
> expectations, and time required to build the tools seem to be a topic
> that needs to be addressed. Under-configured VMs don't finish building
> or take a LONG time.
> 
> I am proposing that I gather performance and configuraton notes for
> building SPARC tools after downloading source on a few configurations:
> 
> + Laptop 2013 i7: Centos on VM
> + Laptop 2013 i7: MSYS2
> + Laptop 2013 i7: Cygwin
> + Laptop 2017 i7: Same three
> + 8 core Xeon Centos native
> + 12 core i7 Fedora native
> 
> One the 2017 7th generation i7, differences in VM configuration can
> result in the build time for sparc tools almost tripling.
> 
> Does this sound useful or confusing? I know it is potentially somewhat
> volatile information. But my old 3rd generation i7 CPU benchmark results
> are comparable to an i5 that is much newer. Plus my old i7 has an SSD
> which many newer i3/i5 laptops do not.
> 
> Feedback appreciated.
> 
> --joel
> 

Hello Joel,

in my experience, the biggest difference in the build time is the number
of cores (in a VM or on a real machine). The processor generation didn't
seem to have that much influence. But I never measured exact numbers.

It might would be a good idea to add some rough numbers somewhere (maybe
in the RSB-manual) so that a new user knows that he has to expect for
example roughly 4 to 6 hours on a single core or about 1/2 to 3/4 of an
hour on a 8 core Linux system. It might could be interesting to have
some rough numbers for other commonly used systems too (like MSYS2,
Cygwin, FreeBSD or MacOS).

I don't think that it is useful to compare processor generations. That
would be an information that would have to be updated on a regular basis
to have any use. I would only add some (few) examples.

If you find any big influences beneath number of cores (you mentioned VM
settings), it might would be worth adding a general section with tips
for speeding up the build process.

Best regards

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

Re: RFC: Value of New Section on Tools Build Time Expectations

2018-10-21 Thread Joel Sherrill

On Sun, Oct 21, 2018 at 2:16 PM Christian Mauderer 
wrote:

> Am 21.10.18 um 19:07 schrieb Joel Sherrill:
> > Hi
> >
> > I am in the middle of reconfiguring my old (~2013 i7) laptop as an email
> > and remote workstation for home. Between helping students and doing two
> > Kick Starts in the past 6 weeks, VM configuration, disk space
> > expectations, and time required to build the tools seem to be a topic
> > that needs to be addressed. Under-configured VMs don't finish building
> > or take a LONG time.
> >
> > I am proposing that I gather performance and configuraton notes for
> > building SPARC tools after downloading source on a few configurations:
> >
> > + Laptop 2013 i7: Centos on VM
> > + Laptop 2013 i7: MSYS2
> > + Laptop 2013 i7: Cygwin
> > + Laptop 2017 i7: Same three
> > + 8 core Xeon Centos native
> > + 12 core i7 Fedora native
> >
> > One the 2017 7th generation i7, differences in VM configuration can
> > result in the build time for sparc tools almost tripling.
> >
> > Does this sound useful or confusing? I know it is potentially somewhat
> > volatile information. But my old 3rd generation i7 CPU benchmark results
> > are comparable to an i5 that is much newer. Plus my old i7 has an SSD
> > which many newer i3/i5 laptops do not.
> >
> > Feedback appreciated.
> >
> > --joel
> >
>
> Hello Joel,
>
> in my experience, the biggest difference in the build time is the number
> of cores (in a VM or on a real machine). The processor generation didn't
> seem to have that much influence. But I never measured exact numbers.
>

I only mention the processor generation because we don't tend to have i3 or
i5
CPUs available but students and users do. My 6-year old i7 benchmarks like a
newer i5. But often i5's don't come with SSDs so they can suffer even more.

Number of cores and RAM are the two big factors. As is making sure you have
enough disk space allocated to avoid turning the entire thing in an
exercise in
frustration.

>
> It might would be a good idea to add some rough numbers somewhere (maybe
> in the RSB-manual) so that a new user knows that he has to expect for
> example roughly 4 to 6 hours on a single core or about 1/2 to 3/4 of an
> hour on a 8 core Linux system. It might could be interesting to have
> some rough numbers for other commonly used systems too (like MSYS2,
> Cygwin, FreeBSD or MacOS).
>

My 7th generation i7 (Dell last fall from last fall) is ~35 minutes for
SPARC as
I tune my VM. A student in a Kick Start with the same laptop turned that
into
a 90 minute build by having 1 core and less RAM. So even with a fast
machine,
the guidance on the VM is important.

Ignoring those who pick tiny virtual HD sizes and then can't even complete
the
build no matter how long they wait.

>
> I don't think that it is useful to compare processor generations. That
> would be an information that would have to be updated on a regular basis
> to have any use. I would only add some (few) examples.
>

The CPU generation wasn't the point. Just that the older one is slower.
Newer
generation ones are often only 20% faster than the old one. Just a
reference point.

>
> If you find any big influences beneath number of cores (you mentioned VM
> settings), it might would be worth adding a general section with tips
> for speeding up the build process.
>

Not failing is the biggest one. I recommend downloading all source first
since that
sometimes fails, doublechecking host packages, and Chris and I moved gdb
before
gcc/newlib in the tools bset so users would fail on that early rather than
last.

That's about it beyond VM tuning and expectations. If you have an i3 with a
5200RPM slow laptop drive, it is going to take a while. We say 30-45 minutes
and we all have nice computers with tuned VMs.

And Windows builds are WAY slower and I can't even give you an estimate at
this point. I just walk away.

So this was just "here's what we know about what to expect and what you can
do to help".

--joel

>
> Best regards
>
> Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RFC: Value of New Section on Tools Build Time Expectations

2018-10-21 Thread Chris Johns

On 22/10/2018 09:11, Joel Sherrill wrote:
> On Sun, Oct 21, 2018 at 2:16 PM Christian Mauderer  > wrote:
> Am 21.10.18 um 19:07 schrieb Joel Sherrill:
> > Hi
> >
> > I am in the middle of reconfiguring my old (~2013 i7) laptop as an email
> > and remote workstation for home. Between helping students and doing two
> > Kick Starts in the past 6 weeks, VM configuration, disk space
> > expectations, and time required to build the tools seem to be a topic
> > that needs to be addressed. Under-configured VMs don't finish building
> > or take a LONG time.

My only concern with VMs is promoting the idea of needing a VM for RTEMS
development. A lot of work has gone into making the tools native across a wide
number of hosts and native tools is the best solution for a user. I hope we
encourage and teach using native tools before a VM.

I have used native RTEMS Windows and Mac tools for development. It can mean
learning some different work flows but in the end it is all rather boringly
similar. The most difficult bit on Windows is debugging and the solution tends
to be remote tcp to a GDB server else where. Who else has used Windows or Mac
for development?

> > I am proposing that I gather performance and configuraton notes for
> > building SPARC tools after downloading source on a few configurations:

What about a link to the builds mailing list archive with something about the
values to look for? Could the host memory and CPU type be added to the email
reports?

> >
> > + Laptop 2013 i7: Centos on VM
> > + Laptop 2013 i7: MSYS2
> > + Laptop 2013 i7: Cygwin

Are there any cygwin build results posted to builds?

> > + Laptop 2017 i7: Same three
> > + 8 core Xeon Centos native
> > + 12 core i7 Fedora native

I would prefer we did not gathering and publish in documentation information
that is hard to be consistent, could be misleading and is of often out of date
as soon as it is published. I remember removing some stuff like this when I
moved the docs to Sphinx as the data was over ten years old. I cannot find it
now in the old doco.

I am fine with the amount of disk space needed to build a tool set and then a
more general comment that the more cores, memory and fast disks you use the
faster the build will be. My Windows builds are on stripped disks.

For Windows you can document the POSIX layer for the shell etc adds overhead
plus virus checking slows the build down so the build directory should be tagged
as a directory not to check. I have no idea how cygwin and Windows Defender
interact but I suspect it will slow things down by a lot and excluding it would
help.

On Windows does the virus scanner scan the VM disk file in real-time or are the
VM's smart enough to have that file excluded?

> > One the 2017 7th generation i7, differences in VM configuration can
> > result in the build time for sparc tools almost tripling.
> >
> > Does this sound useful or confusing? I know it is potentially somewhat
> > volatile information. But my old 3rd generation i7 CPU benchmark results
> > are comparable to an i5 that is much newer. Plus my old i7 has an SSD
> > which many newer i3/i5 laptops do not.
> >
> > Feedback appreciated.
> >
> > --joel
> >
> 
> Hello Joel,
> 
> in my experience, the biggest difference in the build time is the number
> of cores (in a VM or on a real machine). The processor generation didn't
> seem to have that much influence. But I never measured exact numbers.
> 
> I only mention the processor generation because we don't tend to have i3 or i5
> CPUs available but students and users do. My 6-year old i7 benchmarks like a
> newer i5. But often i5's don't come with SSDs so they can suffer even more.
> 
> Number of cores and RAM are the two big factors. As is making sure you have
> enough disk space allocated to avoid turning the entire thing in an exercise 
> in
> frustration. 

Agreed, the RSB has been updated recently to report usage.

> It might would be a good idea to add some rough numbers somewhere (maybe
> in the RSB-manual) so that a new user knows that he has to expect for

Hmm, User manual instead?

I am happy for general guide lines or instructions on improving the experience
for new users with new systems, for example with the latest patch I pushed over
the weekend running a set builder command with `--dry-run` will let you know if
the Python libraries are installed before anything is built. I am not convinced
about the cost/benefit for any specific detail such as build times and host
processor types.

Lets not forget building the tools should be once for a project and not
something you do each week.

> example roughly 4 to 6 hours on a single core or about 1/2 to 3/4 of an
> hour on a 8 core Linux system. It might could be interesting to have
> some rough numbers for other commonly used systems too (like MSYS2,
>

[PATCH] windows: Remove BuildRoot from all configs, add a short tmp path.

2018-10-21 Thread chrisj

From: Chris Johns 

Closes #3562.
---
 bare/config/devel/texane-stlink-1.cfg |  1 -
 rtems/config/tools/rtems-kernel-4-1.cfg   |  1 -
 .../rtems-nios2-gcc-4.1-newlib-1.19.0-1.cfg   |  1 -
 rtems/config/tools/rtems-tools-common-1.cfg   |  1 -
 rtems/config/tools/rtems-tools-git-1.cfg  |  1 -
 source-builder/config/autoconf-2-1.cfg|  1 -
 source-builder/config/automake-1-1.cfg|  1 -
 source-builder/config/binutils-2-1.cfg|  1 -
 source-builder/config/dtc-1-1.cfg |  1 -
 source-builder/config/expat-2-1.cfg   |  1 -
 source-builder/config/freetype-1.cfg  |  1 -
 source-builder/config/gcc-common-1.cfg|  1 -
 source-builder/config/gdb-6-1.cfg |  1 -
 source-builder/config/gdb-common-1.cfg|  1 -
 source-builder/config/gettext-0-1.cfg |  1 -
 source-builder/config/glib-2-1.cfg|  1 -
 source-builder/config/libffi-3-1.cfg  |  1 -
 source-builder/config/libiconv-1-1.cfg|  1 -
 source-builder/config/libjpeg-1.cfg   |  3 +-
 source-builder/config/libpng-1.cfg|  1 -
 source-builder/config/libtiff-1.cfg   |  1 -
 source-builder/config/libtool-2-1.cfg |  1 -
 source-builder/config/libusb-1-1.cfg  |  1 -
 source-builder/config/lwip-1.cfg  |  1 -
 source-builder/config/m4-1-1.cfg  |  1 -
 source-builder/config/microwindows-1.cfg  |  1 -
 source-builder/config/net-snmp-5-1.cfg|  1 -
 source-builder/config/ntp-4-1.cfg |  1 -
 source-builder/config/nxlib-1.cfg |  1 -
 source-builder/config/or1ksim-1-1.cfg |  1 -
 source-builder/config/pixman-0-1.cfg  |  1 -
 source-builder/config/protobuf-2-1.cfg|  1 -
 source-builder/config/qemu-1-1.cfg|  1 -
 source-builder/config/spike-1-1.cfg   |  1 -
 source-builder/config/sqlite-3-1.cfg  |  1 -
 source-builder/config/t1lib-1.cfg |  1 -
 source-builder/defaults.mc|  5 +--
 source-builder/sb/build.py| 32 ---
 source-builder/sb/setbuilder.py   |  1 +
 39 files changed, 19 insertions(+), 57 deletions(-)

diff --git a/bare/config/devel/texane-stlink-1.cfg 
b/bare/config/devel/texane-stlink-1.cfg
index 2f102cc..9d6a157 100644
--- a/bare/config/devel/texane-stlink-1.cfg
+++ b/bare/config/devel/texane-stlink-1.cfg
@@ -17,7 +17,6 @@ Summary:   ST-Link v%{stlink_version} for host %{_host}
 Version:   %{stlink_version}
 Release:   %{release}
 URL:  https://github.com/texane/stlink/
-BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 
 #
 # Source
diff --git a/rtems/config/tools/rtems-kernel-4-1.cfg 
b/rtems/config/tools/rtems-kernel-4-1.cfg
index cdde4c0..8c725a5 100644
--- a/rtems/config/tools/rtems-kernel-4-1.cfg
+++ b/rtems/config/tools/rtems-kernel-4-1.cfg
@@ -18,7 +18,6 @@ Summary:   RTEMS v%{rtems_kernel_version} for target 
%{_target} on host %{_host}
 Version:   %{rtems_kernel_version}
 Release:   %{release}
 URL:  http://www.rtems.org/
-BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 
 #
 # Build if the RSB is released or optionally enable/disable building the RTEMS
diff --git a/rtems/config/tools/rtems-nios2-gcc-4.1-newlib-1.19.0-1.cfg 
b/rtems/config/tools/rtems-nios2-gcc-4.1-newlib-1.19.0-1.cfg
index 28342cd..555956b 100644
--- a/rtems/config/tools/rtems-nios2-gcc-4.1-newlib-1.19.0-1.cfg
+++ b/rtems/config/tools/rtems-nios2-gcc-4.1-newlib-1.19.0-1.cfg
@@ -28,7 +28,6 @@ Summary:   GCC v%{gcc_version} and Newlib v%{newlib_version} 
for target %{_targe
 Version:   %{gcc_version}
 Release:   %{release}
 URL:  http://gcc.gnu.org/
-BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 
 #
 # Supports Candian Cross (Cxc).
diff --git a/rtems/config/tools/rtems-tools-common-1.cfg 
b/rtems/config/tools/rtems-tools-common-1.cfg
index cf86b7e..b15fbce 100644
--- a/rtems/config/tools/rtems-tools-common-1.cfg
+++ b/rtems/config/tools/rtems-tools-common-1.cfg
@@ -9,7 +9,6 @@ Summary:   RTEMS Tools %{rtems_tools_version} for host %{_host}
 Version:   %{rtems_tools_version}
 Release:   %{release}
 URL:  http://www.rtems.org/
-BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 License:   BSD-2-Clause + GPL-2.0
 
 #
diff --git a/rtems/config/tools/rtems-tools-git-1.cfg 
b/rtems/config/tools/rtems-tools-git-1.cfg
index 3573c73..ec44132 100644
--- a/rtems/config/tools/rtems-tools-git-1.cfg
+++ b/rtems/config/tools/rtems-tools-git-1.cfg
@@ -9,7 +9,6 @@ Summary:   RTEMS Tools %{rtems_tools_version} for host %{_host}
 Version:   %{rtems_tools_version}
 Release:   %{release}
 URL:  http://www.rtems.org/
-BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 
 #
 # Prepare the source code.
diff --git a/source-builder/config/autoconf-2-1.cfg 
b/source-builder/config/autoconf-2-1.cfg
index 5061cfd..7062881 100644
--- a/source-builder/config/autoconf-2-1.cfg
+++ b/source-builder/config/autoconf-2-1.cfg
@@ -16,7 +16,6 @@ Summary

Re: [PATCH] Avoid default RTEMS application configuration

2018-10-21 Thread Sebastian Huber


On 20/10/2018 02:04, Chris Johns wrote:

On 19/10/18 5:47 pm, Sebastian Huber wrote:

- Am 18. Okt 2018 um 19:56 schrieb Chris Johns chr...@rtems.org:


On 18/10/18 6:38 pm, Sebastian Huber wrote:

Use a test body with a proper RTEMS application configuration to avoid a
dependency on the default configuration.  Do not include
 directly since this header file is an
implementation detail.

Update #3551.
---
  rtems.py | 30 +-
  1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/rtems.py b/rtems.py
index 1b0da60..c7a1966 100644
--- a/rtems.py
+++ b/rtems.py
@@ -259,13 +259,18 @@ def configure(conf, bsp_configure = None):
  #
  # Checks for various RTEMS features.
  #
-conf.multicheck({ 'header_name': 'rtems/score/cpuopts.h'},
-msg = 'Checking for RTEMS CPU options header',
-mandatory = True)
-load_cpuopts(conf, ab, rtems_path)

OK.


-conf.multicheck({ 'header_name': 'rtems.h'},
-msg = 'Checking for RTEMS header',
-mandatory = True)

Why remove the test? I see the app test below checks for the header however the
test creates a nice specific error message.

The test is not a simple compile test and dosen't only check that you can include 
. In addition it checks that you can link a sample application 
successfully.

The test you have added is a good addition. I am asking, why not keep both
tests? It comes down to the error message and how user friendly it is. If
'rtems.h' is present we can assume it is an installed RTEMS. The second test can
check the quality of the install. I would like to avoid users needing to dig
into a config log to find an error and then try to understand it to figure out
they have a bad path on the command line.


Waf doesn't simply check that you can include a header file. In addition 
it tries to link an executable:


Checking for header rtems.h
==>
#include 

int main(int argc, char **argv) {
    (void)argc; (void)argv;
    return 0;
}

<==
[1/2] Compiling 
[32mbuild/.conf_check_ff53a9f7519945ffcad9ed062861cb10/test.cpp[0m


['/build/rtems/5/bin/powerpc-rtems5-g++', '-qrtems', 
'-B/build/rtems/5/powerpc-rtems5/lib/', 
'-B/build/rtems/5/powerpc-rtems5/qoriq_e500/lib/', '--specs', 
'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', 
'-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', 
'-mstrict-align', '-mstrict-align', '-mspe', '-mspe', '-mabi=spe', 
'-mabi=spe', '-mfloat-gprs=double', '-mfloat-gprs=double', 
'-ffunction-sections', '-ffunction-sections', '-fdata-sections', 
'-fdata-sections', '../test.cpp', '-c', '-o', 
'/scratch/git-rtems-libbsd/build/.conf_check_ff53a9f7519945ffcad9ed062861cb10/testbuild/test.cpp.1.o']
[2/2] Linking 
[33mbuild/.conf_check_ff53a9f7519945ffcad9ed062861cb10/testbuild/testprog[0m


['/build/rtems/5/bin/powerpc-rtems5-g++', '-qrtems', 
'-B/build/rtems/5/powerpc-rtems5/lib/', 
'-B/build/rtems/5/powerpc-rtems5/qoriq_e500/lib/', '--specs', 
'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', 
'-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', 
'-mstrict-align', '-mstrict-align', '-mspe', '-mspe', '-mabi=spe', 
'-mabi=spe', '-mfloat-gprs=double', '-mfloat-gprs=double', 
'-ffunction-sections', '-ffunction-sections', '-fdata-sections', 
'-fdata-sections', 'test.cpp.1.o', '-o', 
'/scratch/git-rtems-libbsd/build/.conf_check_ff53a9f7519945ffcad9ed062861cb10/testbuild/testprog', 
'-Wl,-Bstatic', '-Wl,-Bdynamic']


Using a simple main() requires the default configuration.



What is the error report with just the 'main' test you added and an invalid
RTEMS path?


When I remove the rtems.h from the BSP installation, then I get this:

Building a trivial RTEMS application  : no
The configuration failed
(complete log in /scratch/git-rtems-libbsd/build/config.log)

In config.log:

Building a trivial RTEMS application
==>
#include 
void Init(rtems_task_argument arg) { (void)arg; }
#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER 1
#define CONFIGURE_MAXIMUM_TASKS 1
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
#include 

<==
[1/2] Compiling 
[32mbuild/.conf_check_506c35a0aa2e9f571a9e7ed38df523b2/test.c[0m


['/build/rtems/5/bin/powerpc-rtems5-gcc', '-qrtems', 
'-B/build/rtems/5/powerpc-rtems5/lib/', 
'-B/build/rtems/5/powerpc-rtems5/qoriq_e500/lib/', '--specs', 
'bsp_specs', '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', 
'-msdata=sysv', '-msdata=sysv', '-fno-common', '-fno-common', 
'-mstrict-align', '-mstrict-align', '-mspe', '-mspe', '-mabi=spe', 
'-mabi=spe', '-mfloat-gprs=double', '-mfloat-gprs=double', 
'-ffunction-sections', '-ffunction-sections', '-fdata-sections', 
'-fdata-sections', '../test.c', '-c', '-o', 
'/scratch/git-rtems-libbsd/build/.conf_check_506c35a0aa2e9f571a9e7ed38df523b2/testbuild/test.c.1.o']

err: ../test.c:1:10: fatal error: rtems.h: No such file or directory
 #include

Re: [PATCH] Avoid default RTEMS application configuration

2018-10-21 Thread Chris Johns

On 22/10/2018 16:28, Sebastian Huber wrote:
> On 20/10/2018 02:04, Chris Johns wrote:
>> On 19/10/18 5:47 pm, Sebastian Huber wrote:
>>> - Am 18. Okt 2018 um 19:56 schrieb Chris Johns chr...@rtems.org:
>>>
 On 18/10/18 6:38 pm, Sebastian Huber wrote:
> Use a test body with a proper RTEMS application configuration to avoid a
> dependency on the default configuration.  Do not include
>  directly since this header file is an
> implementation detail.
>
> Update #3551.
> ---
>   rtems.py | 30 +-
>   1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/rtems.py b/rtems.py
> index 1b0da60..c7a1966 100644
> --- a/rtems.py
> +++ b/rtems.py
> @@ -259,13 +259,18 @@ def configure(conf, bsp_configure = None):
>   #
>   # Checks for various RTEMS features.
>   #
> -    conf.multicheck({ 'header_name': 'rtems/score/cpuopts.h'},
> -    msg = 'Checking for RTEMS CPU options header',
> -    mandatory = True)
> -    load_cpuopts(conf, ab, rtems_path)
 OK.

> -    conf.multicheck({ 'header_name': 'rtems.h'},
> -    msg = 'Checking for RTEMS header',
> -    mandatory = True)
 Why remove the test? I see the app test below checks for the header 
 however the
 test creates a nice specific error message.
>>> The test is not a simple compile test and dosen't only check that you can
>>> include . In addition it checks that you can link a sample
>>> application successfully.
>> The test you have added is a good addition. I am asking, why not keep both
>> tests? It comes down to the error message and how user friendly it is. If
>> 'rtems.h' is present we can assume it is an installed RTEMS. The second test 
>> can
>> check the quality of the install. I would like to avoid users needing to dig
>> into a config log to find an error and then try to understand it to figure 
>> out
>> they have a bad path on the command line.
> 
> Waf doesn't simply check that you can include a header file. In addition it
> tries to link an executable:

Thanks, this now makes sense.

> 
> Using a simple main() requires the default configuration.
> 
>>
>> What is the error report with just the 'main' test you added and an invalid
>> RTEMS path?
> 
> When I remove the rtems.h from the BSP installation, then I get this:
> 
> Building a trivial RTEMS application  : no

Should this be:

 Checking for a valid RTEMS BSP installation: no

?

> The configuration failed
> (complete log in /scratch/git-rtems-libbsd/build/config.log)
> 
> In config.log:
> 
> Building a trivial RTEMS application
> ==>
> #include 
> void Init(rtems_task_argument arg) { (void)arg; }
> #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER 1
> #define CONFIGURE_MAXIMUM_TASKS 1
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> #define CONFIGURE_INIT
> #include 
> 
> <==
> [1/2] Compiling 
> [32mbuild/.conf_check_506c35a0aa2e9f571a9e7ed38df523b2/test.c[0m
> 
> ['/build/rtems/5/bin/powerpc-rtems5-gcc', '-qrtems',
> '-B/build/rtems/5/powerpc-rtems5/lib/',
> '-B/build/rtems/5/powerpc-rtems5/qoriq_e500/lib/', '--specs', 'bsp_specs',
> '-mcpu=8540', '-mcpu=8540', '-meabi', '-meabi', '-msdata=sysv', 
> '-msdata=sysv',
> '-fno-common', '-fno-common', '-mstrict-align', '-mstrict-align', '-mspe',
> '-mspe', '-mabi=spe', '-mabi=spe', '-mfloat-gprs=double', 
> '-mfloat-gprs=double',
> '-ffunction-sections', '-ffunction-sections', '-fdata-sections',
> '-fdata-sections', '../test.c', '-c', '-o',
> '/scratch/git-rtems-libbsd/build/.conf_check_506c35a0aa2e9f571a9e7ed38df523b2/testbuild/test.c.1.o']
> 
> err: ../test.c:1:10: fatal error: rtems.h: No such file or directory
>  #include 
>   ^
> compilation terminated.

This a pretty good. The gcc command line has the valid BSP details.

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

[PATCH v2] Avoid default RTEMS application configuration

2018-10-21 Thread Sebastian Huber

Use a test body with a proper RTEMS application configuration to avoid a
dependency on the default configuration.  Do not include
 directly since this header file is an
implementation detail.

Update #3551.
---
 rtems.py | 51 ---
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/rtems.py b/rtems.py
index 1b0da60..038cc11 100644
--- a/rtems.py
+++ b/rtems.py
@@ -143,6 +143,17 @@ def init(ctx, filters = None, version = None, 
long_commands = False, bsp_init =
 if bsp_init:
 bsp_init(ctx, env, contexts)
 
+def test_application(more = []):
+code =  ['#include ']
+code += more
+code += ['void Init(rtems_task_argument arg) { (void)arg; }']
+code += ['#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER']
+code += ['#define CONFIGURE_MAXIMUM_TASKS 1']
+code += ['#define CONFIGURE_RTEMS_INIT_TASKS_TABLE']
+code += ['#define CONFIGURE_INIT']
+code += ['#include ']
+return os.linesep.join(code)
+
 def configure(conf, bsp_configure = None):
 #
 # Check the environment for any flags.
@@ -188,7 +199,7 @@ def configure(conf, bsp_configure = None):
 for ab in arch_bsps:
 conf.setenv(ab, env)
 
-conf.msg('Board Support Package', ab, 'YELLOW')
+conf.msg('Board Support Package (BSP)', ab, 'YELLOW')
 
 #
 # Show and long commands support.
@@ -259,13 +270,10 @@ def configure(conf, bsp_configure = None):
 #
 # Checks for various RTEMS features.
 #
-conf.multicheck({ 'header_name': 'rtems/score/cpuopts.h'},
-msg = 'Checking for RTEMS CPU options header',
-mandatory = True)
-load_cpuopts(conf, ab, rtems_path)
-conf.multicheck({ 'header_name': 'rtems.h'},
-msg = 'Checking for RTEMS header',
-mandatory = True)
+conf.check_cc(fragment = test_application(),
+  execute = False,
+  msg = 'Checking for a valid RTEMS BSP installation')
+load_cpuopts(conf)
 
 #
 # Add tweaks.
@@ -294,7 +302,7 @@ def build(bld):
 if bld.env.LONG_COMMANDS == 'yes':
 long_command_line()
 
-def load_cpuopts(conf, arch_bsp, rtems_path):
+def load_cpuopts(conf):
 options = ['RTEMS_DEBUG',
'RTEMS_MULTIPROCESSING',
'RTEMS_NEWLIB',
@@ -302,27 +310,24 @@ def load_cpuopts(conf, arch_bsp, rtems_path):
'RTEMS_SMP',
'RTEMS_NETWORKING']
 for opt in options:
-enabled = check_opt(conf, opt, 'rtems/score/cpuopts.h', arch_bsp, 
rtems_path)
+enabled = check_cpuopt(conf, opt)
 if enabled:
 conf.env[opt] = 'Yes'
 else:
 conf.env[opt] = 'No'
 
-def check_opt(conf, opt, header, arch_bsp, rtems_path):
-code  = '#include <%s>%s' % (header, os.linesep)
-code += '#ifndef %s%s' % (opt, os.linesep)
-code += ' #error %s is not defined%s' % (opt, os.linesep)
-code += '#endif%s' % (os.linesep)
-code += '#if %s%s' % (opt, os.linesep)
-code += ' /* %s is true */%s' % (opt, os.linesep)
-code += '#else%s' % (os.linesep)
-code += ' #error %s is false%s' % (opt, os.linesep)
-code += '#endif%s' % (os.linesep)
-code += 'int main() { return 0; }%s' % (os.linesep)
+def check_cpuopt(conf, opt):
+code =  ['#ifndef %s' % (opt)]
+code += ['  #error %s is not defined' % (opt)]
+code += ['#endif']
+code += ['#if %s' % (opt)]
+code += ['  /* %s is true */' % (opt)]
+code += ['#else']
+code += ['  #error %s is false' % (opt)]
+code += ['#endif']
 try:
-conf.check_cc(fragment = code,
+conf.check_cc(fragment = test_application(code),
   execute = False,
-  define_ret = False,
   msg = 'Checking for %s' % (opt))
 except conf.errors.WafError:
 return False;
-- 
2.16.4

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

Re: [PATCH v2] Avoid default RTEMS application configuration

2018-10-21 Thread Chris Johns

On 22/10/2018 16:46, Sebastian Huber wrote:
> Use a test body with a proper RTEMS application configuration to avoid a
> dependency on the default configuration.  Do not include
>  directly since this header file is an
> implementation detail.

Looks good. Please push.

Will you update libbsd and examples-v2?

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

Re: [PATCH v2] Avoid default RTEMS application configuration

2018-10-21 Thread Sebastian Huber


On 22/10/2018 08:13, Chris Johns wrote:

On 22/10/2018 16:46, Sebastian Huber wrote:

Use a test body with a proper RTEMS application configuration to avoid a
dependency on the default configuration.  Do not include
 directly since this header file is an
implementation detail.

Looks good. Please push.


Thanks for the review.



Will you update libbsd and examples-v2?


Yes.

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

RFC: Value of New Section on Tools Build Time Expectations

Re: RFC: Value of New Section on Tools Build Time Expectations

Re: RFC: Value of New Section on Tools Build Time Expectations

Re: RFC: Value of New Section on Tools Build Time Expectations

[PATCH] windows: Remove BuildRoot from all configs, add a short tmp path.

Re: [PATCH] Avoid default RTEMS application configuration

Re: [PATCH] Avoid default RTEMS application configuration

[PATCH v2] Avoid default RTEMS application configuration

Re: [PATCH v2] Avoid default RTEMS application configuration

Re: [PATCH v2] Avoid default RTEMS application configuration

10 matches

Site Navigation

Mail list logo

Footer information