User manual and new build system

Chris Johns chrisj at rtems.org
Sun Nov 24 22:47:26 UTC 2019


On 23/11/19 1:31 am, Sebastian Huber wrote:
> On 22/11/2019 15:25, Joel Sherrill wrote:
>> On Fri, Nov 22, 2019, 8:19 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>     I am about to add the documentation of the new build system to the user
>>     manual. There is no longer a bootstrap of the sources necessary. Should
>>     I remove all information for the bootstrapping from the user manual?
>>     Should there be a chapter for the old build system?
>>
>> Don't remove the old process until the code is removed. I thought we had
>> agreed to a final autoconf based release. A release with both will help ensure
>> it is functionally equivalent and provide a baseline for comparison.
> 
> I would remove the old build system as soon as possible. Shipping a release with
> two build systems makes maintenance more difficult. Getting rid of
> Automake/Autoconf would remove these packages from the RSB build for example.

After a some consideration over the weekend I am not sure what we should do and
I think we need to discuss it some more.

We need to answer the important question of user churn. A change of this type
will have a flow on effect to established users and any infrastructure they have
to build and deploy RTEMS. An example is the `5/bsps` build sets in the RTEMS, a
build system change breaks those configurations. I am sure there are many other
scripts in use today. I also know there are sites running 4.11 and 5 in parallel
and building each will break.

We need to decide if this churn to our users is something we want now.

I currently do not favor a release with both build systems being present.

If we decide it is OK to have the churn we can proceed as we currently are. The
build changes can be merged and the autotools build system can be removed.

If we decide we would like to make RTEMS 5 the last autotools release we need to
make the release and that would mean a focused effort by more than just me. We
cannot leave all the hard work done by Sebastian for a new build system on hold.

Either path effects someone, a developer, for example Sebastian, our users with
churn or me and I hope other core developers with a release.

A release means getting the release itself debugged then we need to test it. It
also means there may be possible changes and we need to be mindful of the effect
that might have on the work Sebastian has already done.

I look forward to hearing what our developers and community think.

Chris


More information about the devel mailing list