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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
