<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 21, 2018 at 4:00 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19/1/18 5:12 pm, Sebastian Huber wrote:<br>
> The RSB policy with respect to configuration files is not clear to me. I thought<br>
> these are read-only files that will be never removed?<br>
<br>
</span>That policy was established when the RSB was building a number of releases from<br>
a single code base. The branching moved us away from that and now the need is a<br>
distance memory. After the branching I did not want to change too much at once.<br>
<br>
The RSB is now stable. Adding the ability to detect orphans means we can see<br>
which files are not referenced and by inspection which are not top level and so<br>
can be removed. Looking at the 4.10 branch I felt having a config file to build<br>
a gcc-7 compiler is misleading.<br>
<span class=""><br>
> If you want to keep only<br>
> the files used by the build sets, then why do they have file names with a<br>
> version included?<br>
<br>
</span>There is no need any more. Further to this looking back I wonder about the<br>
usefulness. What evolved is a better use of the scripting language to enable and<br>
disable features in a single set of files. I did not see this when the RSB was<br>
started but looking back now it makes perfect sense.<br></blockquote><div><br></div><div>I tend to disagree. It makes it clear which versions are being built and we </div><div>do have the situation where different targets are built using different tool</div><div>versions. On top of that, we have had cases where basic tools don't come</div><div>from the main site. I think the or1k may still be in that situation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> Are branches in the RSB really practical? Each time something changes you have<br>
> to back port it throughout the branches. When you build the tools you have to<br>
> specify the version. So, what is the benefit of the branches?<br>
><br>
<br>
</span>I do not think the alternative is good either, a single RSB that can build any<br>
branch. This exposes us to changes for one branch leaking into other branches. A<br>
single change for an updated newlib requiring we regression build all support<br>
branches. Also it opens up a release for a version being used to build another<br>
version.<br></blockquote><div><br></div><div>We have branches for every repository. This shouldn't be any different. </div><div><br></div><div>Plus it helps avoid a situation Chris and I discussed where it pushes new requirements</div><div>onto old releases. For better or worse, they were what they were. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The Python core is stable and there are good API between each of the modules. I<br>
do not think there has been any language changes so scripts are compatible. I<br>
suspect you could copy the `source-builder/sb` to any branch and it would work.<br>
<br>
I think the fact we will make a 4.10 branch release and we can build tools on<br>
modern hosts including MacOS and Windows is a big improvement. I do not think we<br>
could build Windows tools like this when 4.10 was first released.<br></blockquote><div><br></div><div>I think the RPMs built to provide tools on Cygwin. Using native Windows tools</div><div>is much better. And that's ignoring the value of the RSB versus providing </div><div>binaries.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am open to any ideas that improve how we use and manage the RSB.<br></blockquote><div><br></div><div>I don't want to move away from release branches or including the versions</div><div>in the files. </div><div><br></div><div>Having the versions in the files makes it easy to upgrade all but one or two</div><div>architectures.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>