How will user's compile with Makefiles? Was: Re: large bss size for sample applications

[Chris Johns]

On 2/10/2015 10:59 am, Peter Dufault wrote:
> Chris, Makefile isn’t custom support, it’s legacy support.

Yes I agree. I am not saying "there will be no ability to add Makefile
support for user applications", rather I am saying there is the ability
to offer good Makefile support that works for all BSPs and we can make
this support work in future releases. It is really pleasing to me to
hear you and Pavel are passionate about this because we need people who
know this stuff. I am not the best person to add the user application
Makefile support.

What I am saying is the current support is broken and we cannot maintain
it as it stands because the way things work in some BSPs is entrenched
in Makefile logic and we cannot express this easily in a way we can
export as an interface. Any change internal to RTEMS and the BSPs is
visible to users. This works in both directions, we cannot break
existing users with 4.11 and we cannot clean up and change RTEMS
internally and it is hurting us.

> For better or for worse, if you add barriers to Makefiles you raise eyebrows in the legacy community.

I am really puzzled about where I said I wanted to raise barriers. I
though I said the opposite. I must not be expressing myself clearly.

We have 2 very separate parts, the first is the RTEMS kernel package and
the second is user applications. They are currently joined at the hip
and this is not a good thing.

The intention is to have the kernel build as a package and what we use
is for this is waf. It is internal to the kernel package and only
visible to those who maintain or update code and BSPs in the kernel.
Users of RTEMS never see the internal way RTEMS is maintained and the
only external view of waf is invoking it to configure, build and
install. The intention is to have no support for any user build systems
only rtems-config.

The second part is user application build support and my hope is users
of the various build systems such as make, waf, cmake, automake etc
create packages to help support building applications.

>  They can understand an effort to adapt from BSD make to GNU make, but a lack of Makefile support is a check-box not checked.

I am not really following this. To use 'rtems-config' in GNU make all
you need to do is something like (this is made up by me):

 CC=$(shell rtems-config cc)
 LD=$(shell rtems-config ld)
 CFLAGS=$(shell rtems-config cflags)
 LDFLAGS=$(shell rtems-config ldflags)

This could be in a template in a git repo on rtems.org or a wiki page.
What ever works. Pavel has raised possible performance issues and we
need to consider this when the time comes. In my example this is just a
few shell forks which is fast.

>  I don’t know of any other build systems that have the footprint of “make”.
> 
> Yes, the twisty auto* mess is a mess, but it does promise Makefile support.

But this is internal to the RTEMS kernel package. I thought this is
about user applications.

> 
> If you think time has passed this issue by I’d like to know, I don’t think it has.
> 

I am sorry but I do not understand this statement.

Chris

>> On Oct 1, 2015, at 16:27 , Chris Johns <chrisj at rtems.org> wrote:
>>
>> Where does this leave other build systems? What if each build system's
>> users start to request custom support? Allowing custom support adds an
>> extra burden to the RTEMS maintainers to make sure no one breaks. RTEMS
>> developers are not build system experts so this just dilutes our
>> efforts. We need to find a suitable middle ground for everyone.
> 
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> 
> This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering.  Contact HDA to discuss methods we can use that ensure secure communication.
>