On 30/09/2014 6:40 pm, Sebastian Huber wrote:
On 29/09/14 08:15, Chris Johns wrote:
Why do we not move the tool chain patches back to the RTEMS sources? I
think it would be nice if you can check out a particular RTEMS version
and then use the RSB and say: build me the tool chain for this version.
I am ok with the INI file that defines the tools for a release being
held in
RTEMS and the build system checking the tools however at this point in
time I
do not think is it a good idea to move everything into RTEMS. I have
not given
the idea much consideration but I see issues with the validation
process. For
example the tools and RTEMS can move independently of each other and
on head
this is a little more difficult however with a release things are much
more
stable. This means a dot point release of RTEMS does not require a dot
point
version of tools.
My view may change as what we have moved too settles and maybe I am just
hesitant to move too quickly here.
In case you have an RTEMS release and then a tool chain patch change is
necessary, can't you simply do this update in the RTEMS release branch?
You need a branch update anyway to bring in the new INI/XML file
describing the current tool chain intended for this RTEMS version.
Yes this is correct and an XML/INI file in rtems is something I support.
It defines the project's supported and tested tool set. The definition
file(s) should be positioned out front in the top level directory.
It is the patches in the rtems source tree and having RTEMS build the
tools I am not as sure about.
The tools are a table of architecture vs source and patches for each
tool component. These tables are large and what is used varies. If we
move to tool patches in the RTEMS source tree a number of issues appear.
Take the openrisc support. It is currently based on a specific non-FSF
version of gcc as the openrisc project merges its support upstream into
the FSF repo. The RSB allows this and I support it happening because it
has allowed RTEMS to get support added and a successful GSoC project to
happen this year plus I am confident the openrisc project will complete
the merge. Does having the tool patches in rtems require we take the FSF
code those tools are based on, create a diff and add it to RTEMS or do
we create exceptions to the rule ?
There is also a dependence issues between the RSB and RTEMS. At the
moment you can get a copy of the RSB and build the tools and RTEMS
(--with-rtems). I often get emails related to 4.10 so this is used by
users for the previous release of RTEMS. On the other hand I like the
idea of getting the RTEMS source and configuring to say I want a
sparc/sis BSP and then having RTEMS build a set of tools and then the
BSP. These are 2 different use cases. The RSB leading the way is an
architecture tool set for a number of BSPs and an RTEMS internally built
tool set specific to a BSP or group of BSPs.
Finally Windows tools are not able to be built from source on Windows.
Performance issues aside the msys and cygwin support plus recent make
bugs have limited the success. It is possible to get a thin script to
build a tool set from source however this has proven more difficult with
the RSB for a number of reasons some of which are listed in the RSB doco
under the Windows section.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
