GNU bug report logs - #54020
document libtool compile-specific flags in manual

Previous Next

Full log

Message #57 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Bogdan <bogdro_rep <at> gmx.us>
Cc: 54020 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#54020: Allow user-defined libtool options
Date: Wed, 17 Jan 2024 00:04:43 -0500

[Message part 1 (text/plain, inline)]

On 14 Jan 2024 18:55, Bogdan wrote:
> Mike Frysinger <vapier <at> gentoo.org>, 2024-01-14 02:06:
> > On 13 Jan 2024 22:29, Bogdan wrote:
> >> Mike Frysinger <vapier <at> gentoo.org>, 2024-01-13 07:19:
> >>> On 15 Mar 2023 17:31, Bogdan wrote:
> >>>>     Another patch from my side. This one makes it possible for users to
> >>>> pass additional options to libtool in 'compile' mode. Fixes #54020.
> >>>>
> >>>>     Added documentation and a test case including the '-no-suppress'
> >>>> option. All tests with 'lt' or 'libtool' in the name pass.
> >>>>
> >>>>     Feel free to rename the variables, I just came up with the names
> >>>> LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
> >>>> where the variables are put and the mode they're used in.
> >>>
> >>> why do we need LTCOMPILE_POSTFLAGS ?  isn't that just after the compile
> >>> command ?  $obj_compile expands into e.g.
> >>> 	\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
> >>>
> >>> so if someone wants to add flags to C/etc..., they already have knobs
> >>> to turn.
> >>>
> >>> which means this would simplify by only having one variable right ?
> >>> AM_LTCOMPILE_FLAGS
> >>
> >>    Seems so, at least for now. At least for C compilers. At least until
> >> $obj_compile becomes something else in the future or something more,
> >> or even now contains (or will contain) other options after $(CFLAGS)
> >> on the command line when using other compilers.
> >>    For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
> >> suffice, at least now, as it seems. I've made pre- and post- flags for
> >> better flexibility, to be future-proof.
> >
> > i don't see there ever being a future need here.  libtool's design is that
> > it stops processing after the first non-argument after --mode=compile, and
> > everything else is a wrapped command which libtool blindly executes.  those
> > commands should have their own set of flags, and libtool is irrelevant at
> > that point, so giving it a libtool-centric name that is used regardless of
> > the wrapped command will never make sense.
> 
>   And that's probably something I wasn't aware of. If it's
> dead/useless code, feel free to remove this part. The fact that I made
> a patch doesn't mean that it must be applied as a whole and never changed.

the point of posting patches for review is to review and discuss and learn.
maybe you saw something or an angle that i missed.  i don't know everything.
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.