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

[dufault at hda.com]

> On May 10, 2019, at 08:07 , Sebastian Huber <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>  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?

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/20190510/49f88867/attachment.html>