[PATCH] rtems: Remove unused configuration files.

[Joel Sherrill]

On Sun, Jan 21, 2018 at 4:00 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 19/1/18 5:12 pm, Sebastian Huber wrote:
> > 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?
>
> That policy was established when the RSB was building a number of releases
> from
> a single code base. The branching moved us away from that and now the need
> is a
> distance memory. After the branching I did not want to change too much at
> once.
>
> The RSB is now stable. Adding the ability to detect orphans means we can
> see
> which files are not referenced and by inspection which are not top level
> and so
> can be removed. Looking at the 4.10 branch I felt having a config file to
> build
> a gcc-7 compiler is misleading.
>
> > If you want to keep only
> > the files used by the build sets, then why do they have file names with a
> > version included?
>
> There is no need any more. Further to this looking back I wonder about the
> usefulness. What evolved is a better use of the scripting language to
> enable and
> disable features in a single set of files. I did not see this when the RSB
> was
> started but looking back now it makes perfect sense.
>

I tend to disagree. It makes it clear which versions are being built and we
do have the situation where different targets are built using different tool
versions. On top of that, we have had cases where basic tools don't come
from the main site. I think the or1k may still be in that situation.


>
> >
> > 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?
> >
>
> I do not think the alternative is good either, a single RSB that can build
> any
> branch. This exposes us to changes for one branch leaking into other
> branches. A
> single change for an updated newlib requiring we regression build all
> support
> branches. Also it opens up a release for a version being used to build
> another
> version.
>

We have branches for every repository. This shouldn't be any different.

Plus it helps avoid a situation Chris and I discussed where it pushes new
requirements
onto old releases. For better or worse, they were what they were.


>
> The Python core is stable and there are good API between each of the
> modules. I
> do not think there has been any language changes so scripts are
> compatible. I
> suspect you could copy the `source-builder/sb` to any branch and it would
> work.
>
> I think the fact we will make a 4.10 branch release and we can build tools
> on
> modern hosts including MacOS and Windows is a big improvement. I do not
> think we
> could build Windows tools like this when 4.10 was first released.
>

I think the RPMs built to provide tools on Cygwin. Using native Windows
tools
is much better. And that's ignoring the value of the RSB versus providing
binaries.


>
> I am open to any ideas that improve how we use and manage the RSB.
>

I don't want to move away from release branches or including the versions
in the files.

Having the versions in the files makes it easy to upgrade all but one or two
architectures.


>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180121/26986c9f/attachment.html>