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

[Chris Johns]

On 1/10/2015 11:46 am, Pavel Pisa wrote:
> Hello Chris and others,
> 
> I have no problem if most of RTEMS makefiles are replaced by something
> better but I would really regret if 
> 
>   /opt/rtems4.11/arm-rtemsX.YY/BSP_Z/Makefile.inc
> 
> file is not generated and installed during BSP build process.
> 

Please see my response on the devel list to this issue...

https://lists.rtems.org/pipermail/devel/2015-September/012646.html

> This file holds enough information to build complex application
> with same setting as is the one used to build BSP.

This is an important requirement for the generation of code for all
build systems and not just users of make. There are also warnings and
other settings used in RTEMS and BSPs that get exported and these should
not. These exported flags break a number of 3rd party libraries. I have
code in a number of places to filter flags into groups so builds works.

> And I would prefer if these variables values are preserved
> after install in some form which can be directly read by GNU make.

As I state in my devel list post we will provide a specific tool to
manage the interface and when the time comes I suggest Makefile support
is built around that interface.

> I can imagine calling some pkgconfig like tool to obtain these
> values but it would mean that we have to run that tool once
> and store/cache results somewhere in the build to not suffer from
> overhead to call the tool when make is parsing makefile in each
> directory.

I am sorry but I have no feel for the performance issues involved. I
appreciate we need to be mindful of the impact on users and any added
complexity such as caches (shudder). I can only offer we work together
to find a suitable solution that works for everyone and meets the new
broader requirements RTEMS has these days.

> The question is if to keep /opt/rtems4.11/make/custom . If defines
> are directly inlined in BSP specific Makefile.inc it can
> be even better.

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.

> May it be that I am too afraid of changes. But example which
> I fear off is my experience with MBED testing. It uses python
> based build system or provides Eclipse integration. I have not been
> able to integrate it with our build system yet even that base MBED
> build only generates libraries as RTEMS does. But it is optimized
> to generate Makefiles based packages as partial distributions
> for companies EDKs but not for install and use from own applications.
> Used compiler parameters are hidden in python based build system
> or in complete but easily not reusable makefiles generated for given
> exported example.

I completely understand and wish to avoid the experiences you describe.

What you describe I have been fighting but with RTEMS for years. I do
not use the make support for RTEMS and have not for years and it is not
fun keeping things going.

> We cannot switch to WAF only build for our application code
> because it would not support Linux userspace and kernelspace,
> about 20 different systemless embedded hardware targets from
> H8S, nRF51, LPC, MSP430 etc. and crosscompile to RTEMS
> and Linux on more archs from single source submodules
> trees usually symlinked at toplevel of target specific
> build tree.

No one is asking you to most of all me. I want RTEMS to support any
build system just not directly.

> So, please, do not hide basic setting.  Store it in some
> simple human and make readable form in BSP install directory
> as a list of assignments. There is not much more required
> to build application if these values are exported.

We need to provide an interface we can maintain and we need to make it
suitable for all users including you. My fear of a specific file format
is expanding the work RTEMS has making sure the file and it's format
does not break users. Make gets used in complex and fragile ways and
issues can be subtle.

Chris