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