large bss size for sample applications

[Jeff Webb]

On 09/28/2015 08:50 AM, Gedare Bloom wrote:
> On Mon, Sep 28, 2015 at 9:42 AM, Jeff Webb <jeff.webb at nta-inc.net> wrote:
>> On 09/26/2015 01:36 AM, Chris Johns 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.
>>
>>
>> Thanks for the heads up.  Sorry, but I'm not quite sure what "the waf build
>> of RTEMS" means.  Does this mean that the next release of RTEMS can only be
>> built using waf (and thus user applications must use it, too), or does it
>> mean that in the next release, if RTEMS is built using waf, applications
>> will also have to be built using waf?  I'm not too concerned with how the
>> RTEMS core libraries are built, but I am interested in knowing the
>> constraints placed on the application developer.  What I really want to know
>> is will there be a way for users to build their applications using make, or
>> is waf the only option going forward?
>>
> We're discussing this on the devel mailing list to resolve the above
> statement, which I think refers specifically to the mechanisms of the
> RTEMS Application Makefiles, and not to the general use of 'Makefile'
> as an application build system. Make should continue to be supported,
> but perhaps the mechanics of the current approach will change
> slightly. As a community-oriented project, we are keen to ensure that
> users face the least resistance, which also means trying to expand
> support to other platforms where Make is less well-supported.
>
> I think the above statement was just worded a bit vaguely.

Thanks for the clarification.  That sounds great.

-Jeff