On Wed, 3 Jul 2024 at 00:58, Nick Bowler <nbow...@draconx.ca> wrote: > For autoreconf to work with libtool there just needs to be a definition > of LT_INIT available when it runs autoconf for the first time, in order > for the traces to indicate an expansion of LT_INIT. There are a variety > of ways this might happen. > > Since libtoolize copies its macro files into the project workspace, in a > typical configuration aclocal still will pick up definitions from the > workspace, even if it doesn't actually know how to find the installed > macro definitions. Then autoreconf will run libtoolize, which copies > them in, and re-runs aclocal which should find the (possibly updated) > definitions. > > So I'd only expect to encounter any issue if running autoreconf from > a "clean" workspace that has not previously run libtoolize. Or if > libtool.m4 has been deleted prior to running autoreconf. So unless > some care is taken to ensure the test environment really is the same > every time it's possible that the "working" results are just a fluke. >
The typical bk-based workflow for NTP developers is to start with a clean clone of the repo which does not contain any libtool .m4 files or autotools output, and run the bootstrap script to bring the repo into a similar state as one would get from an extracted make dist tarball. bk doesn't have branches, so we typically always have a 'clean' workspace to start, as each "branch" is another copy of the repo. It occurs to me we might avoid issues along these lines by having our bootstrap script invoke libtoolize before autoreconf. Does that sound wise to the two of you? But none of this is meant to suggest that there isn't actually some real > change in aclocal behaviour which is causing the results you are seeing. > Yes, and it's always good to understand these sorts of potential regressions, but it might not justify more investigation given other productive uses of volunteer developers' time if others aren't seeing it. -- Cheers, Dave Hart
