Conditionalize make behavior e.g. disable --gc-sections

[dufault at hda.com]

> On May 10, 2019, at 18:42 , Chris Johns <chrisj at rtems.org> wrote:
> 
> On 10/5/19 10:27 pm, dufault at hda.com wrote:
>> 
>> 
>>> On May 10, 2019, at 08:07 , Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>> 
>>> On 10/05/2019 13:58, Gedare Bloom wrote:
>>>> On Tue, May 7, 2019 at 5:03 AM Peter Dufault<dufault at hda.com
>>>> <mailto:dufault at hda.com>>  wrote:
>>>>> What is best practice to change build behavior?  e.g. I need to use
>>>>> --whole-archive/--no-whole-archive in one place but --gc-sections breaks it
>>>>> and that's turned on for the BSP (xilinx_zynq_a9_qemu).
>>>>> 
>>>>> I’ve done this in the .cfg files for the BSP:
>>>>> 
>>>>> ifneq ($(RTEMS_GC_SECTIONS_DISABLE),1)
>>>>> LDFLAGS_GC_SECTIONS_DISABLE = -Wl,--gc-sections
>>>>> endif
>>>>> 
>>>>> (...)
>>>>> 
>>>>> LDFLAGS = $(LDFLAGS_GC_SECTIONS_DISABLE)
>>>>> 
>>>>> and then I set RTEMS_GC_SECTIONS_DISABLE=1 in the one Makefile where I need
>>>>> it.  I don’t see similar patterns, is this the way to do it?
>>>>> 
>>>> Historically a new BSP variant has been introduced when there needs to
>>>> be a change at this .cfg level. But, I could see a rationale to
>>>> include this kind of switching behavior at a higher level. Someone
>>>> might consider how to integrate it into our configure.ac/Makefile.am
>>>> black magic, but that is beyond me:).
>>>> 
>>>> An alternative approach that may work from what you propose is to use
>>>> following in the xilinx zynq .cfg file:
>>>> LDFLAGS ?= -Wl, --gc-sections
>>>> then, you can provide own LDFLAGS = -Wl on your make command line or
>>>> in your Makefile, I think that would work bit more elegant
>>> 
>>> Nobody forces you to use -Wl, --gc-sections to link your application. For the
>>> RTEMS tests and samples this shouldn't be an issue?
>>> 
>> My make pulls in those settings.  I think it is best to use the same settings
>> that the RTEMS tests and samples unless I have a good reason to change them,
>> e.g., I need —whole-archive in one application in one place.
>> 
>> What do you recommend?  Where is an example to build from?
> 
> We do not have simple examples with documentation to support them. I receive a
> stream of requests about building libdl applications and all I can do is point
> user to the testsuite Makefile.am's.
> 
> The Makefile.inc approach has a range of problems so adding documentation and
> examples based on it is something I do not support. The approach I would like to
> see happen is documented in https://devel.rtems.org/ticket/3302.
> 
> You do not need to build applications with the exact same flags that the kernel
> uses however you need to be careful in managing what you do use. As I state in
> the ticket RTEMS Tools [1] and RTEMS Waf [2] both have support to filter the
> CFLAGS into parts so you can manage what is used when building applications. I
> would prefer this is formalised when exported by RTEMS rather than having to
> have this fragile code which does break from time to time.
> 
> Chris
> 
> [1] https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n79
> [2] https://git.rtems.org/rtems_waf/tree/rtems.py#n793 <https://git.rtems.org/rtems_waf/tree/rtems.py#n793>

I’ll make a summary and then move on to other items.  Thanks all, I’ve gotten what I need from the discussion.

Gedare: I don’t like “?=“ in any complicated setting because you need to hunt around to make sure nothing has already over-ridden default behavior.  A “request” such as setting RTEMS_GC_SECTIONS_DISABLE=1 is globally clear as to what it is trying to be accomplish at a local level and harder to responsibly break.

Sebastian: I still don’t understand what your comment suggests, I almost never feel forced to do anything.  When using a BSP I want to build with the settings used by the developer and that the tests are run on.  I don’t want to modify them much unless I need to.  In this case the standard settings break another flag. You don’t need to answer - this is not that important.

Chris: Your response is appropriate for the -devel list and beyond where I want to go on this subject right now.  I’ll add the requirement that someone coming from a Makefile based build system must find it easy to get started with RTEMS and incorporate the libraries into their project without digging deeply into details.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190512/4fbbf641/attachment-0002.html>