Building RTEMS hello world image using CMake

[Chris Johns]

On 14/03/2016 09:33, Pavel Pisa wrote:
> Hello Chris and others,
>
> On Sunday 13 of March 2016 22:28:14 Chris Johns wrote:
>> On 13/03/2016 1:53 AM, Gedare Bloom wrote:
>>> If this works for you, and you are sufficiently interested, it would
>>> be useful to provide CMake example for the examples-v2.git repository
>>> for others to benefit.
>>
>> I am not sure about adding this to examples-v2.git. I would prefer it to
>> be a waf only build system. I am not sure if make support is still
>> present and working but it will go once Makefile.inc goes as it is not
>> supported in the new RTEMS waf build system.
>
> please, consider to keep/add some mechanism, rule etc.
> to export Makefile.inc equivalent content to some file
> in /opt/rtems/arch/bsp directory in easily readable form
> (make, shell assignments or some other sed parsable format).

We have discussed this before in detail. I refer you to the thread from 
October last year .. 
https://lists.rtems.org/pipermail/devel/2015-October/012659.html.

> I could try to find how to do that when I find time to
> switch to 4.12 and WAF. I think, that it is so minimal
> information and it worth to be archived/documented with
> installed BSP anyway and if it is in easily readable form
> then it is better.

The project as a whole needs to address this issue in a robust method 
and what is made available as an interface for make file based 
applications should be the same interface for waf, cmake, scons, nmake, 
jam, or even a hand written batch file on Windows (haha).

> I see future when this information is not stored and easily
> readable from installed libraries tree, as a real problem,
> so I vote to not cut support for other make systems
> for applications.

RTEMS installs many files that are not human readable, for example all 
library archives and tools, (nm, readelf etc) are provided to examine 
them. The problem with easy to read files and exposing this type of 
information is users not using the provided API and then being 
disappointed when the format changes. Being able to easily access and 
review the information installed is important, it maybe via a provided tool.

> How you propose to maintain for
> example Microwindows and other libraries in future?

https://lists.rtems.org/pipermail/devel/2015-October/012666.html

Being able to build a make based application is not going away. What 
RTEMS uses to build itself is the domain of the RTEMS kernel and should 
not effect any user application in anyway. We could decide to build 
RTEMS using manually edited Power Shell batch files only on Windows and 
a user's application should not notice.

Makefile.inc is broken because it exports internal information we cannot 
control and maintain and we have no choice in what we do. We cannot 
state these leaking internal makefile fragments are now part of the 
formally exported API and we cannot determine what users have used on 
purpose or by accident. We can only create an API and move forward and 
address specific user issues as they arise. The key issue internally in 
RTEMS with the BSP .cfg files is the wide variations of how things are 
done and it is this that exported. I suspect most BSP developers never 
considered what they did in a BSP deep in RTEMS was visible to user 
applications and nor should they have needed too.

The other important fact is not all users use make or Makefile.inc 
because it is only usable in make based application. I am one because 
Makefile.inc is inherently broken and leaks uncontrollable details into 
applications. This means for a long time, and I would say easily over 10 
years RTEMS has left other build systems users out in the cold. This 
needs to end and we need to provide support for all possible build systems.

> If these libraries are rewritten to WAF build then
> each time when mainline is changed it would require
> to analyze and update WAF based fork. May it be that
> it stay to be solved by RSB. But again forcing every project
> and application to be build through RSB is not win either.

<sigh> This is not what is being stated and it never has. Please do not 
confuse the fact the examples-v2 is using waf as a statement that all 
RTEMS applications _must_ be built with waf. The whole point of offering 
the idea of a separate repo dedicated to _all_ builds system is to 
collect this information and provide some sample code built in different 
ways. Here is a link to the up coming RTEMS User Manual's comment on 
Open Source .. 
https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/overview/index.html#open-source. 
The last paragraph is true for all parts of a user's project including 
build systems.

>
> Some mechanism to build Automake and Autoconf based projects
> should to be considered as well or option to build broad range
> of POSIX compliant packages against RTEMS would be complicated
> too. I do not use Autoconf/Automake for RTEMS projects now
> but it is thing which should be taken into account.
>
>  From my projects perspective, it would be real problem
> to rewrite set of my projects which contains consistent
> build system over many git submodules where many libraries
> and even whole application compile to Linux userspace, Linux kernel,
> RTEMS, Windows and many bare metal targets. I have about 30
> automake-like fragments which are over 20kB long in my
> largest project build for RTEMS. It needs to be maintained
> for RTEMS-4.10 for long time due testing and instrument certification
> but I want to keep run it against RTEMS development version
> to catch problems and regressions in time. When I rewrite
> all that fragments to the WAF then I have to keep WAF
> in sync with other stuff which counts hundreds (may it be 500)
> such make fragments and their total length is in hundreds kB.
> So thinking about rewrite and forking is really nightmare
> dream for me. For sure, I would look how to implement some hack
> to extract required information to file as I do for Linux modules
> build for example but it is not ideal solution.

I understand. I cannot say what is offered will be 100% suitable yet, I 
suspect you need to make some changes. What I would like to offer is the 
hope these changes will be once, this is the intended aim.

> So I hope and vote for some Makefile.inc alternative
> to be available even in future RTEMS versions.

If course, and I would like to further extend the requirements to say 
that the interface used remains stable across future RTEMS releases and 
stable across all BSPs and architectures supported by RTEMS in a 
release. We currently cannot meet this requirement.

Chris