bug#54020: Allow user-defined libtool options
Bogdan via Bug reports for Automake <[email protected]> Sun, 14 Jan 2024 18:55:50 +0100
| Newsgroups | gmane.comp.sysutils.automake.bugs,gmane.comp.sysutils.automake.patches |
|---|---|
| Message-ID | <[email protected]> |
Mike Frysinger <[email protected]>, 2024-01-14 02:06: > On 13 Jan 2024 22:29, Bogdan wrote: >> Mike Frysinger <[email protected]>, 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 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. -- 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