All installed host tools are removed from the RTEMS sources - next steps?
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Jun 20 06:18:13 UTC 2018
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.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list