On 18/06/18 08:39, Chris Johns wrote:
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.
Yes, BSP-specific stuff should definitely be not in a separated repository.
Why is the build system in a separate repository?
I don't think that a single global file would lead to a merge hot spot,
we don't add that many BSPs per day. I am still more in favour of
per-BSP configuration files (no scattered BSP-specifics throughout the
code base).
It would be nice to have the configuration data in a simple format (e.g.
Makefile fragment, INI, pkg-config) and not as a Python source file.
What about the post-link steps?
Should we also consider the BSP configuration options? This area is a
lot more complicated and time consuming to change. I would like to post
pone this and concentrate on build system issues first, e.g. location
and format of compiler flags.
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.
Do you want to use the pkc-config files internally or only export them
to the installed BSP? The *.cfg files are Makefile fragments and not
pkc-config files.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
