Compressed patch to move make/custom/* to make/*

[Chris Johns]

On 9/2/18 7:07 pm, Sebastian Huber wrote:
> On 09/02/18 00:47, Chris Johns wrote:
>>>      No user should be forced to touch its Makefiles only because we move some
>>>      files in the RTEMS source tree from A to B. So, I think the install
>>> location
>>>      should remain as is.
>>>
>>>
>>> I agree but I think you missed my point. The use in testsuites can be fixed
>>> to point
>>> to the source tree.  But if I change the includes in the "custom" files, I have
>>> concerns
>>> that it may not be possible to make it work in both when building and installed.
>>>
>> Exporting anything internal to users is always going to present a risk, we have
>> known and acknowledged this for years. It has been part of the reason we have
>> avoided making changes in the build system however my attitude is changing or
>> has changed, ie removing preinstall.
>>
>> Long term I cannot see how we can sustain this interface and that means we need
>> to determine when it goes? I am more than happy to be proved wrong. It is only
>> fair to those who use these installed files they get suitable warning and we
>> need to figure out what we provide to replace it.
>>
>> Building new applications and products based on this type of application build
>> framework with RTEMS 5 should be discouraged. We are looking to increase the
>> release frequency and this will only shorten the life span for these files.
>>
> 
> I think it will not cost much to simply leave this stuff as is.

>From a file exporting point of view sure, however do we need to ensure anything
internal is consistent with the export requirements that exist? If we get a
conflict which side has to handle it?

The ability for BSP developers to add any valid make syntax means we do not know
what is actually being used by users of a BSP. The post link format support is
an example and another is the special link addresses, for example the rtems_waf
support for building with waf from the .pc files has to hold tweaks [1] because
there is no standard means to handle exporting this info from the make syntax to
anything else so it is not present. As a result I am pretty sure we will break
things.

[1] https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n325

> It should be
> easy to support with any RTEMS internal build system. The only thing we really
> need are the machine flags for the BSP.

What about post-link formatting? If we limit RTEMS to building just to the ELF
then that is true.

> We need a better place to specify them.

Do we move all the detail to pkgconfig format files we can just export as a copy
and then have RTEMS's build system use those to extract the pieces it needs?

I am OK with pkgconfig because there are a few implementations about that are
not based on the recursive build process of the main package. One is in the RSB
and rtems_waf packages written in Python.

> The blocking points for the next step of build system clean up are from my point
> of view (highest priority first):
> 
> 1. The host tools, they should move to rtems-tools or even go away if no longer
> used. Getting rid of the native compiler for BSP builds will simplify things.

Good idea.

> 2. The libcpu, the files should move to bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/* or
> bsps/@RTEMS_CPU@/shared/*.

Top level 'bsp' or 'arch', an 'arch' directory is a sort of a defacto standard?
Could you have arch/@RTEMS_CPU@/score, arch/@RTEMS_CPU@/contrib,
arch/@RTEMS_CPU@/dev, arch/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/* etc?

I just wonder if adding CPU support like this under bsps is making extra rules
like bsp/@RTEMS_BSP_FAMILY@/* == arch?

> 3. Move the machine flags out of the *.cfg files. Make them usable by arbitrary
> build systems.

As suggested above we could move them to .pc files and then have the build
system use them?

I think we need to consider more than the just the machine flags.

> 4. Make the BSP options independent of Autoconf, so that it can be used from
> Autoconf and other build systems.

Same.

Chris