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

Tue Sep 29 11:22:35 UTC 2015

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.Sherrill at oarcorp.com> wrote:
>>>
>>>
>>>
>>> On September 26, 2015 9:52:37 AM CDT, "Thomas Dörfler" <Thomas.Doerfler at 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 <dufault at hda.com>
>>>> Datum:
>>>> An: Gedare Bloom <gedare at rtems.org>
>>>> Cc: Amar Takhar <verm at darkbeer.org>,"rtems-devel at rtems.org"
>>>> <devel at 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 <gedare at 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 <chrisj at 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
>>>>>> users at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/users
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at 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 at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at 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.