All installed host tools are removed from the RTEMS sources - next steps?

[Chris Johns]

On 18/06/2018 15:41, Sebastian Huber wrote:
> 
> I finished the tasks to remove the installed host tools from the RTEMS sources.
> Only one tool was moved to the RTEMS tools - rtems-bin2c. The other tools were
> remove due to license issues, limited usability, or general obsolescence. Now, a
> host compiler is no longer necessary to build RTEMS. This can be used to
> simplify the RTEMS build, since we only have to deal with the cross compiler.

Thank you for these changes.

> The BSP sources and header files were moved some weeks ago to "bsps/*", but the
> build files (configure.ac and Makefile.am) are still in "c". The next goal is to
> move also the build files to "bsps/*". The long term goal is the introduction of
> a new build system based on waf. Each change in the current build system should
> make it easier to introduce the new build system.

With all these changes I suspect a new build system is going to distill down to
the configuration details and the management of that data.

An example Amar created is:

https://git.rtems.org/amar/waf.git/tree/py/waf/defaults/bsp/arm.py?h=archive/waf/2015-06
https://git.rtems.org/amar/waf.git/tree/py/waf/defaults/options.py?h=archive/waf/2015-06

I am not sure a like a single file for the whole of RTEMS, it could becomes a
merge hot spot plus I do not like having it in the build system source tree. I
see the build system files and the data that drives it as separate. You should
be able to roll out build system v2, v3 etc and the data stays consistent.

I do not know if we want to localize the data to the functionality being
configured, for example shell configuration in the shell source. I think is
makes sense for a BSP. I think a hierarchy is a good thing so there can be reuse
of common configuration data.

> 
> I think one result of previous discussions is to use pkg-config format for
> BSP-specific build system input as a replacement of the bsps/*/*/config/*.cfg
> files.
> 
> https://en.wikipedia.org/wiki/Pkg-config
> 

Yes I agree with using this format. The difficult part of this is capturing the
details needed to create a suitable set of flags. The current config files are
make format meaning there is no standard pattern and each BSP needs to be
reviewed. We can also consider using variables and a variable query to add extra
detail if we need it.

> We could temporarily add a Makefile rule to generate the first version of the
> new BSP-specific file, e.g. bsps/arch/bsp/config/some-bsp.pc. Then build all
> BSPs to get the initial content for the RTEMS sources.

Why replace the existing one, why not make it better? The rtems_waf support for
applications is using the existing file now. It is not perfect but it does work.

> What do we want to do with the standard Makefile support in "c/src/make" and
> "make"?

I am not sure I understand what this means?

Chris