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

[Chris Johns]

On 3/10/2015 2:25 am, Pavel Pisa wrote:
> Hello Chris,
> 
> On Friday 02 of October 2015 11:25:23 Chris Johns wrote:
>> 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.
> 
> Yes that is generally OK. You are right that overhead is small
> and we use same setup with pkgconfig in some cases already.
> If caching is required then it is probably better
> on application side then on infrastructural.

Yes. Users are open to create what they can and need.

> But rtems-config tool makes me a little nervous.

I am please to see the feedback and the concern.

> If it is part
> of RTEMS BSP install directory then it is in a perfect match with
> RTEMS sources version used to build BSP. If it is installed
> to /opt/rtems4.xx (given version install prefix) then it can be
> problem if there are more BSPs build at different time and you do not use
> different prefix for each. If rtems-config is global then you have
> to maintain solution to be compatible with all RTEMS builds and versions
> in future. So from my side, I would prefer mostly stable file location
> and format as the values source than the tool.

Yes I agreed. We currently tend to have versioned trees because the
tools with newlib and the kernel need to be in sync and the tools reside
in $PREFIX/bin. This may change. I am not sure.

The last time I looked which is well over 18 months ago, maybe longer
the rtems-config tool's interface was there but the questions you ask
needed to be considered and addressed. I think the tool was the per BSP
type.

The change over to waf is far from completed and there is plenty to do
to make is fully production ready. What is known and is really good is
the speed it can build RTEMS. To get an idea I suggest build the new
networking stack.

> 
> But both would work and if the tool has pkgconfig compatible syntax
> then it would have some advances. Or even "database" format can be
> directly compatible with pkgconfig even that it is not my
> preferred format.
> 
> Important form me is if solution is checked/discussed enough
> to catch possible problems which would be hard to correct
> in future.

There are posts from Amar back in February and March on the changes. We
are looking to get things moving and to start bringing the work on to
the main repo. It will be complication and there will be more
discussions and as a result what we have will have to evolve.

Chris