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

[Chris Johns]

On 2/10/2015 11:51 am, Pavel Pisa wrote:
> Hello all,
> 
> On Thursday 01 of October 2015 23:59:05 Peter Dufault wrote:
>> Chris, Makefile isn’t custom support, it’s legacy support.  For better or
>> for worse, if you add barriers to Makefiles you raise eyebrows in the
>> legacy community.  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
>> 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.
> 
> In the fact, I think there is no replacement generic enough for autoconf.
> But it can be used without automake, for example GIT uses this setup.
> 
> As for RTEMS, I do not mind if automake and autoconf are eliminated.
> I have stuck on simple atempt to copy of rtems/testsuites/libtests/tar02 to rtems/testsuites/samples/tar02 now.
> I hoped to speedup that way preparation of testcase for untar
> 4.11 regression (build RTEMS only with --enable-tests=samples).
> But for some reasons bootstrap/automake does not understand my intention.
> And generally, I do not like automake too much.
> 
> On the other hand, there are many clean (GNU) make based large
> projects - Linux kernel etc. In that regard, I like much Linux
> kernel configuration system which allows to configure complex
> combinations of options with interdependencies. More projects
> use standalone version of these tools with their (usually make
> based) build systems
> 
> http://ymorin.is-a-geek.org/projects/kconfig-frontends

There was a GSoC project this year about a config GUI for RTEMS.

> 
> Important is that whole selected configuration is stored in human
> readable form and can be versionned.

Interesting point. The data will be an easy to parse text type format
but we can change it as we see fit so rtems-config is the interface.

> 
> But CMAKE combined with Ninja seems to work well for ReactOS
> and there exist much more well working options.
>

I thought this discussion is about user applications and not the RTEMS
kernel.

FYI I use cmake on various projects because I have too and wish not to
be involved with its use here if that ever happened.

> As for RTEMS BSP parameters, my preference is if they are stored
> in clean, human and tools readable form after installation.
> The current make compatible format (i.e. lines KEY=VALUE)
> looks to me as sane. I have some fear if that information
> is installed in form of some algorithm/tool even common to
> more BSPs that I cannot be confident with long term guaranteed
> exact match to the values used during BSP build.

Can a configure type phase be used to build such a file if the runtime
overhead proves to high?

> There is not so much required. I.e. values for
> CC or CC_FOR_TARGET, etc. (AS, AR, LD ..), CFLAGS, CPPFLAGS,
> LDFLAGS and LIBS. 

Agreed and there are other things that may be present to help users, eg
SMP, FP support, device and driver details, device defaults etc.
Remember there is the whole BSPOPTS stuff in RTEMS the user has no
access to.

> The most other is in bsp_specs and linkcmds.
> Or is it expected to remove these as well?
> 
> Where is expected be stored this infomation in the new build
> system after BSP install?

It is stored in something rtems-config can report. The waf support for
building RTEMS has a long way to go and this part is still evolving. I
cannot stop you digging inside to the get at the data you want but we
reserve the right to change the format.

Chris