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

[Chris Johns]

On 20/06/2018 16:18, Sebastian Huber wrote:
> 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.

The focus being on simple, anything serious would hit compatibility issues
pretty quickly.

An install of the source tree as it is today places some these files into the
install tree. I can see an "external package" finding the installed .pc files
and querying them or loading the contents and writing out a suitable .cfg file.
Installing this package would install the support type files, eg leaf.cfg etc,
and the generated .cfg files. The point being if you define an interface via .pc
you can generate the .cfg files. You cannot go the other way, we tried.

> If we want to move it out the RTEMS sources, then there are some
> license issues.

What is the issue? Would the license stay as is even if the source stays the
same or is modified?

> If we want to switch to a BSD license for the RTEMS sources,
> then we have the same issue.

Yes removing is the cleanest solution.

> A concrete next step would be to move the stuff from "c/src/make" to "make" to
> concentrate this in one spot.

I have no real view. Getting to have a single copy of the various files is a
good thing.

Chris