Chris,
thank you for your detailed posting. Having a stable build interface is
important for user acceptance. Setting it on a better-defined basis than
the current "it is as it is" makes sense.
But before we onnounce it, we should at least have a plan on how it will
look like. Otherwise we will generate lots of confusion, which does not
lead to anything.
wkr,
Thomas.
Am 29.09.2015 um 13:13 schrieb Chris Johns:
Hi,
Sorry about the slow response. I have been travelling.
As Joel points out the current Makefile support for applications can not
continue forward in its current form. The method used grew to what it is
today and we now have something we cannot sustain. Any refactoring of
the building system for RTEMS to any possible build system tool would
face the same problem. It is not specifically related to using waf to
build RTEMS.
I cannot guarantee what will happening with the the current application
Makefile support going forward and we need to warn users. This does not
mean Makefile support for applications will not be possible, it just
means the current way it is implemented will need to change and this
means the values, settings and configurations may not the same and may
impact users of the current Makefile support offered.
The key technical issue is the direct exposure of the internals used to
build a BSP. The BSP is basically exported directly into the user's
Makefile and so into their build system. Over the years various hacks,
tweaks and features of make have been used and as a result RTEMS
developers have no control over how a BSP is built and defined nor how a
user should build an app for a BSP. The current application Makefile
support sort of works for a user using Makefiles how ever it means no
other build system can be used and apart from not being equatable it is
just not a good outcome for RTEMS users long term.
RTEMS needs to regain control of the settings, flags or what ever is
needed by a user to build an application for a BSP. This means RTEMS
needs to provide an interface which is stable, robust and users can
depend on. It needs to be consistent across all BSPs. As a result Amar
has defined 'rtems-config' a host based tool that reports various
settings and values when asked. For those who know it is similar to
pkgconfig. With a suitable interface what happens inside RTEMS is of no
concern to a user.
The other part of this is the RTEMS eco-system. This is a community
driven initiative to support specific niches users have and I invite
everyone to get involved. I tend to use waf where I can because I like
it and it is addictive. It is built on a great language, super fast, and
has great platform support but this is just my interest and want. I
welcome others to provide support for other build system such as
Makefile, cmake, scons, or what ever when we finally get the RTEMS waf
build and rtems-config released. With a suitably defined interface using
'rtems-config' the support for these build system should be stable and
able to support all BSPs.
To highlight this please note the rtems_waf support for applications
resides in my personal repo. For those interested the rtems_waf support
has some basic support for 'rtems-config' [1] as well as tweaks [2] for
the current pkgconfig support in RTEMS that is broken and can never be
made to work for the reasons I list above.
Chris
[1] https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n624
[2] https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n264
On 27/09/2015 10:11 am, Peter Dufault wrote:
I think there should be a requirement that you can deploy an RTEMS release at a
site strictly using Makefiles. Not develop RTEMS or build RTEMS, but deploy
RTEMS.
I would prefer, but won’t go so far as to say it is a requirement, that one
should be able rebuild a deployed BSP with changes via Makefiles.
The barriers to using RTEMS in a subsystem at a company not committed to RTEMS
must be kept as low as possible, and the additional work to someone suggesting
RTEMS (me) must be kept as low as possible.
On Sep 26, 2015, at 11:13 , Joel Sherrill <joel.sherr...@oarcorp.com> wrote:
On September 26, 2015 9:52:37 AM CDT, "Thomas Dörfler"
<thomas.doerf...@embedded-brains.de> wrote:
Peter's statement gets a +1 for me. Makefile integration IMHO makes
using RTEMS in many development systems rather easy. Forcing Waf for
user development is a drawback.
How can we avoid this?
There are two pieces here.
+ a file with the list of tools, flags, etc.
+ the existing application Makefile structure.
The application Makefile infrastructure is so old it predates automake. Long
ago, I had a shell script called automake to generate them. This is before even
releases on tape were shipped. Yes, pre-ftp.
The first piece captures basic information required to integrate into any big
system.
The second is obsoleting an application Makefile system that has been present
since before RTEMS was on ftp. I have no idea how widely it is used. But we
don't have a formal decision on it that has been through user community review.
I think all the core developers wouldn't mind removing it but we have no idea
of the impact.
If there is a high impact, we may be able to capture it as something not used
inside RTEMS but as a kit for users. It rarely changes and depends on the first
piece which I think we still need to publish with a BSP.
A hard requirement is that we can't force a build system on users. We can
provide guidance for popular options we may not personally use but that's about
it. Instructions for Eclipse or Visual Studio integration for example.
Wkr Thomas.
-------- Ursprüngliche Nachricht --------
Von: Peter Dufault <dufa...@hda.com>
Datum:
An: Gedare Bloom <ged...@rtems.org>
Cc: Amar Takhar <v...@darkbeer.org>,"rtems-de...@rtems.org"
<devel@rtems.org>
Betreff: Re: How will user's compile with Makefiles? Was: Re: large bss
size for sample applications
I don’t like this requirement. I think it’s fine for development but
want to be able to deliver a package that will integrate into a
client’s Makefile based build system where they can make changes and
re-build. In other words, I don’t mind if building a BSP or updating
RTEMS requires waf, but want to be able to deploy and make minor
changes without it.
Up to now I’ve been able to get the existing Makefile fragments to work
at multiple sites with a little work.
On Sep 26, 2015, at 09:04 , Gedare Bloom <ged...@rtems.org> wrote:
The comment below, made in the users ml, caught me off guard. How
will
user's applications build when RTEMS is built with Waf?
If there is a complex answer, then this conversation belongs here on
the devel ml until we can sort it out.
Gedare
On Sat, Sep 26, 2015 at 2:36 AM, Chris Johns <chr...@rtems.org>
wrote:
On 25/09/2015 11:04 pm, Jeff Webb wrote:
On 09/25/2015 07:59 AM, Gedare Bloom wrote:
The next task for me will be to set up a simple out-of tree C or
C++
POSIX
application.
Thanks again for all the help!
-Jeff
Simple examples for out-of-tree builds exist in the
examples-v2.git
repository with the "RTEMS Application Makefile" approach using
custom
Makefiles, and with the "RTEMS Application Waf" approach using
wscripts and a git-submodule for waf support. The former is an
older,
established way to build applications linking to an 'installed'
RTEMS,
and the latter is a newer way to do it.
Perfect! This is just what I need. Thanks for the pointer.
The Makefile approach will not be supported with the waf build of
RTEMS
when it lands.
Chris
_______________________________________________
users mailing list
us...@rtems.org
http://lists.rtems.org/mailman/listinfo/users
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email, like most email, is delivered unencrypted via internet
email protocols subject to interception and tampering. Contact HDA to
discuss methods we can use that ensure secure communication.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--joel
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email, like most email, is delivered unencrypted via internet email
protocols subject to interception and tampering. Contact HDA to discuss
methods we can use that ensure secure communication.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
