bug#54020: Allow user-defined libtool options

[Mike Frysinger]

On 13 Jan 2024 22:29, Bogdan wrote:
> Mike Frysinger <vapier@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.
-mike

signature.asc
Description: PGP signature