On 18/06/18 08:57, Chris Johns wrote:
On 18/06/2018 16:43, Sebastian Huber wrote:
On 18/06/18 08:39, Chris Johns wrote:
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?
We have this standard Makefile support for applications:
https://git.rtems.org/rtems/tree/c/src/make/README
This stuff depends on the *.cfg files and would need an update if we use
pkg-config files.
Externally reflecting the internal build system and state to applications was a
mistake. We have no idea how these the files we have exported have been used
because there is no controlled API at the config file level. I do not think we
can create an API now that is workable and does not break users. This is why the
original pkg-config effort stalled.
We need to make some difficult choices. I see the end of the road for this
support as it exists.
I see make builds being supported in a standard pkg-config way which is a
positive. The support around pkg-config for a number of important build systems
is mature including make.
If this type of support is needed to be backwards compatible I suggest an
external tool is written that generates these files with the data in a suitable
format that provides some backwards compatibility. This tool could be part of
the RTEMS Tools project or stand alone like rtems_waf.
The main objective is having a single standard API, ie pkg-config, and the
eco-system builds on that API for the various build systems that exist.
If this is accepted you are free to make changes in the build system without
needing to consider external applications. I think this will be important when
making things simpler and cleaner.
I would like to keep the support for this stuff (at least the main
functionality, I already broke the INSTALL_VARIANT feature), if it is
not too time consuming. You can use it to build simple applications for
a huge range of RTEMS versions. If we want to move it out the RTEMS
sources, then there are some license issues. If we want to switch to a
BSD license for the RTEMS sources, then we have the same issue.
A concrete next step would be to move the stuff from "c/src/make" to
"make" to concentrate this in one spot.
--
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
