On 15/11/17 22:13, Chris Johns wrote:
On 13/11/2017 18:56, Sebastian Huber wrote:
There will be no 5.1.X release with X != 0. We have a version scheme change and
not simply a major version number bump. I think is quite good explained in the
GCC development page how it works (Version Numbering Scheme for GCC 5 and Up):
https://gcc.gnu.org/develop.html
I knew there was some discussion about using this model, I was not aware this
was the agreed path. I am fine with this approach and support it.
We need something similar in the new engineering guide.
Yes. Should the wiki page [1] be updated to make it clear the approach we are
taking until we have an engineering doc?
I updated:
https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
What do you mean with separate prefixes? I doubt that you can build a RTEMS 4.1
with the tool chain of RTEMS 4.10 and vice versa.
Using the gcc approach changes this and what you say makes sense. In this
context I was out by a dot number.
/opt/rtems/5/bin/X-rtems5-gcc
/opt/rtems/6 (maybe with the new build system)
/opt/rtems/7/bin/X-rtems7-gcc
I am looking at the parallel install issue (#3083) and unfortunately a rather
complex fix to it I am attempting to find the simplest path into the build
system and stumbled across this in cpukit/aclocal/rtems-top.m4:
AC_PREFIX_DEFAULT([/opt/rtems-][_RTEMS_API])
Does this need to change to:
AC_PREFIX_DEFAULT([/opt/rtems/][_RTEMS_API])
?
Yes, I think this is more in line with:
https://docs.rtems.org/branches/master/user/installation/prefixes-sandboxing.html#project-sandboxing
In this manual:
|/bd/rtems/4.11.0/tools|
Production prefix for RTEMS 4.11.0 compiler, debuggers and tools.
|/bd/rtems/4.11.0/bsps|
Production prefix for RTEMS 4.11.0 Board Support Packages (BSPs).
What should be the content of "tools" and "bsps"?
--
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
