Richard Biener <richard.guent...@gmail.com> writes:
> On Wed, May 14, 2025 at 6:29 PM James K. Lowden
> <jklow...@schemamania.org> wrote:
>>
>> On Wed, 14 May 2025 11:04:50 +0200
>> Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>>
>> > Work around what appears to be a GNU make bug handling MAKEFLAGS
>>
>> Before I say Yes, could someone please tell me why this rumored bug is
>> responsible for so much boilerplate in our Makefile.am files? You
>> say,
>>
>> > Unlike some runtime libs that can get away without setting
>> > AM_MAKEFLAGS and friends, libgcobol can not since it then tries to
>> > link the 64-bit libgcobol with 32-bit libstdc++.
>>
>> but I don't see the connection between that and 20 lines of definition
>> resting on "what appears to be a bug".
I certainly agree that this is quite a mouthful.
>> I guess I can live with "no one knows, that's what we do." But I'm
>> sure I'm not alone in preferring to understand how the build builds.
>
> That's the case ... though this boilerplate is not used consistently.
Well, I guess variables are added that are only needed in certain
runtime libs (like GDC* stuff in libphobos). And, as it so often
happens in GCC development, were copied from another instance when a new
runtime lib was added.
In hindsight, I wonder if we couldn't move the common parts to
multilib.am and only add the specific ones in the runtime libs that need
them. Haven't tried that yet: my immediate concern is getting the build
working.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
