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

[Pavel Pisa]

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

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

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

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.

There is not so much required. I.e. values for
CC or CC_FOR_TARGET, etc. (AS, AR, LD ..), CFLAGS, CPPFLAGS,
LDFLAGS and LIBS. 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?

Best wishes,

              Pavel