On Wed, Feb 24, 2021 at 08:03:06AM -0800, Rafael Ávila de Espíndola wrote: > Stuart Henderson <s...@spacehopper.org> writes: > > > On 2021/02/23 17:17, Rafael Ávila de Espíndola wrote: > >> > >> Stuart Henderson <s...@spacehopper.org> writes: > >> > >> > On 2021/02/23 15:25, Stuart Henderson wrote: > >> >> I'll do some testing, I'm using this updated diff > >> > > >> > Oh yuk, gnu m4 is now needed at runtime for libtoolize. > >> > Is there a way around that? > >> > >> This is probably from > >> > >> - GNU M4 is required to run libtoolize in a directory with a > >> 'configure.ac' (or 'configure.in') that needs tracing to determine > >> what modes and directories have been specified. > >> > >> But unfortunately I have no idea how to avoid it, sorry. Maybe > >> libtoolize could be on its own sub package and only that depends on m4? > > > > A subpackage for libtoolize makes no sense. libtoolize and the libtool.m4 > > files are literally all that are used by most ports using devel/libtool. > > Perhaps it can be persuaded to run with /usr/bin/m4 though, it depends > > what it wants from gm4. > > Scrap that then. It is the first time I hear about libtoolize and the > manual page made me think it was something that was run once when > starting a project that uses libtool: > > DESCRIPTION > Prepare a package to use libtool.
Do not feel bad, most of libtool is a shitshow. you do think "yeah it's gonna be used that way", and then you go "oh no they wouldn't" (yes they will) you did set foot into a VERY unpalatable place. Here there might be dragons. (do not feel bad, though... there are still dragons in newer projects, they're called meson or cmake instead of autocrap, but they still fail in hilarious ways)
