> From: Gavin Smith <[email protected]> > Date: Thu, 15 Jan 2026 21:51:54 +0000 > > On Thu, Jan 15, 2026 at 09:27:51PM +0100, [email protected] wrote: > > > I think it's likely the XS modules were used in your test run. I think > > > it's a good idea to report at the start of the output whether XS modules > > > are enabled. > > > > If we do that (it is not clear to me where to do that, as the tests are > > independent), I think that it would be better to be more specific than > > XS/non XS, but rather show up to which step is XS used, by using the > > information in the TEXINFO_XS_* environment variables, and also the > > information in TEXINFO_XS_EXTERNAL_*. Also, if that kind of information > > is output for tests of texi2any, it could be a good thing to add the > > information on whether the Perl texi2any or the C texi2any > > implementation is used. > > I don't know of a way to do it easily. I looked at the Automake documentation > and couldn't see a way to put extra stuff in test-suite.log. There is > the ${AM_TESTSUITE_SUMMARY_HEADER} variable but this appears only to be output > to standard output at the end of the tests (not at the beginning), > and not put in the log file. > > It could be enough to check config.log files or the values of Makefile > variables > to check if XS was enabled or not.
The reason I asked is that Windows has some peculiar rules for how it finds and loads shared libraries. Unlike Posix systems, on Windows the DLL files are supposed to be either in the same directory as the executable file of the program which loads them, or from a system directory where DLLs are usually installed, or somewhere on PATH (which on Windows includes the current directory of the running process). (This is a simplification; the actual rules are much more complex, see https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-unpackaged-apps and https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) Since the tests run with Terxinfo uninstalled, I wonder whether the test suite harness sets things up so as to find and load the DLLs just built. Showing that as part of the test would go a long way towards flagging any issues with finding the DLLs, and will also indicate which parts of the code were actually tested -- the Perl code or the equivalent C code. Right now, I have no idea. And looking in config.log and Makefile's doesn't help, because I already know the configure script concluded the extensions could be built, and I also know that they were in fact built. I just don't know whether they were used when running the test suite. Which brings me to the installation. I've just run "make install", and I see that various libtexinfo*.dll DLLs are installed in $prefix/lib/bin. What I don't know is whether they will be found and loaded at run time. Can you explain how this is set up when running texi2any? Which program will load them? (Strangely, ctexi2any.exe, which I presumed will load them, is not installed.) Are the DLLs loaded by explicit dlopen calls, which use their full absolute file names? Or are they supposed to be found by the system's library search, about which I explained above? Same question about the DLLs in lib/texinfo/, although in that case we already know this works from the experience of the previous Texinfo releases, as long as the Perl code which handles that was not modified in some way that broke it. Another question related to "make install" is why are the *.dll.a files installed in lib/texi2any/ ? These are the so-called "import libraries", which are needed on Windows to link applications against shared libraries. But there's no feature in Texinfo that needs to allow other applications to be linked against the DLLs and XS extensions produced by the build, is there? The same goes to the *.la files -- they are only needed for linking against the libraries (and that is not Windows-specific); so why are they installed?
