bug#54020: Allow user-defined libtool options

[Bogdan]

Mike Frysinger <vapier@gentoo.org>, 2024-01-17 06:04:
> On 14 Jan 2024 18:55, Bogdan wrote:
> > Mike Frysinger <vapier@gentoo.org>, 2024-01-14 02:06:
> > > 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.
> >
> >    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


 No problem. I hope I didn't sound rude or something, because that
wasn't the purpose. My mail was (supposed to be) completely neutral. I
don't get angry or something if someone reviews my patch, or modifies
it, or even completely rejects it.
 I don't know everything either and I my only purpose with adding 2
flags was to be just-in-case future-proof (so that we don't get a
similar report some time later, saying "can you make a flag like that,
because I need one after the invocation as well?", and not to support
something that already exists.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org