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

Tue Sep 29 11:13:52 UTC 2015

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
> 