<div dir="ltr"><div><div><div><div><div><div>Hi,<br></div>Sorry for the delay. I am attaching my CMakeLists.txt with this.The test.c is the source code from examples-v2. I created  a separate build folder to hold the builds. And from inside that gave the command <br></div>$ cmake ..<br></div>and then for the generated makefile,I gave the command<br></div>$ make all<br></div>After the executable was created,I used the simulator to get the output<br>$ $HOME/development/rtems/4.11.0-rc1/bin/sparc-rtems4.11-run ./HELLO<br></div>And then I got the ouput as<br>*** MODIFIED HELLO WORLD TEST ***<br>Hello Sambeet!How are You?<br>*** END OF MODIFIED HELLO WORLD TEST ***<br><br><div><br><div><div><br><div> <br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 5:14 AM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14/03/2016 09:33, Pavel Pisa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Chris and others,<br>
<br>
On Sunday 13 of March 2016 22:28:14 Chris Johns wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13/03/2016 1:53 AM, Gedare Bloom wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this works for you, and you are sufficiently interested, it would<br>
be useful to provide CMake example for the examples-v2.git repository<br>
for others to benefit.<br>
</blockquote>
<br>
I am not sure about adding this to examples-v2.git. I would prefer it to<br>
be a waf only build system. I am not sure if make support is still<br>
present and working but it will go once Makefile.inc goes as it is not<br>
supported in the new RTEMS waf build system.<br>
</blockquote>
<br>
please, consider to keep/add some mechanism, rule etc.<br>
to export Makefile.inc equivalent content to some file<br>
in /opt/rtems/arch/bsp directory in easily readable form<br>
(make, shell assignments or some other sed parsable format).<br>
</blockquote>
<br></span>
We have discussed this before in detail. I refer you to the thread from October last year .. <a href="https://lists.rtems.org/pipermail/devel/2015-October/012659.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2015-October/012659.html</a>.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I could try to find how to do that when I find time to<br>
switch to 4.12 and WAF. I think, that it is so minimal<br>
information and it worth to be archived/documented with<br>
installed BSP anyway and if it is in easily readable form<br>
then it is better.<br>
</blockquote>
<br></span>
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).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see future when this information is not stored and easily<br>
readable from installed libraries tree, as a real problem,<br>
so I vote to not cut support for other make systems<br>
for applications.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How you propose to maintain for<br>
example Microwindows and other libraries in future?<br>
</blockquote>
<br>
</span><a href="https://lists.rtems.org/pipermail/devel/2015-October/012666.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2015-October/012666.html</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If these libraries are rewritten to WAF build then<br>
each time when mainline is changed it would require<br>
to analyze and update WAF based fork. May it be that<br>
it stay to be solved by RSB. But again forcing every project<br>
and application to be build through RSB is not win either.<br>
</blockquote>
<br></span>
<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 .. <a href="https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/overview/index.html#open-source" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/overview/index.html#open-source</a>. The last paragraph is true for all parts of a user's project including build systems.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some mechanism to build Automake and Autoconf based projects<br>
should to be considered as well or option to build broad range<br>
of POSIX compliant packages against RTEMS would be complicated<br>
too. I do not use Autoconf/Automake for RTEMS projects now<br>
but it is thing which should be taken into account.<br>
<br>
 From my projects perspective, it would be real problem<br>
to rewrite set of my projects which contains consistent<br>
build system over many git submodules where many libraries<br>
and even whole application compile to Linux userspace, Linux kernel,<br>
RTEMS, Windows and many bare metal targets. I have about 30<br>
automake-like fragments which are over 20kB long in my<br>
largest project build for RTEMS. It needs to be maintained<br>
for RTEMS-4.10 for long time due testing and instrument certification<br>
but I want to keep run it against RTEMS development version<br>
to catch problems and regressions in time. When I rewrite<br>
all that fragments to the WAF then I have to keep WAF<br>
in sync with other stuff which counts hundreds (may it be 500)<br>
such make fragments and their total length is in hundreds kB.<br>
So thinking about rewrite and forking is really nightmare<br>
dream for me. For sure, I would look how to implement some hack<br>
to extract required information to file as I do for Linux modules<br>
build for example but it is not ideal solution.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I hope and vote for some Makefile.inc alternative<br>
to be available even in future RTEMS versions.<br>
</blockquote>
<br></span>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Chris<br>
</font></span></blockquote></div><br></div>