On Mon, Feb 02, 2026 at 11:04:11PM +0100, Patrice Dumas wrote: > On Mon, Feb 02, 2026 at 09:44:14PM +0000, Gavin Smith wrote: > > On Mon, Feb 02, 2026 at 10:18:28PM +0100, Patrice Dumas wrote: > > > Maybe we should change the name of the conditional, then, for example to > > > BUILD_C_LIBRARIES? > > > > XS modules are still a C library. > > Ok. So what about > BUILD_SHARED_TXI_LIBRARIES > Or maybe even better > SHARED_TXI_LIBRARIES_BUILT
The whole point of the BUILD_C_CODE condition was not to build C code under tta/ if it was not necessary. There may be some reason that some other condition is also needed just for the auxiliary, non-XS dynamic libraries (libtexinfo and so on) but that was not the main point of the change. > To me it is clearer. Indeed, the HAVE_ICONV was used to mean that some > code depends indirectly on the iconv library through the shared > libraries. A conditional like SHARED_TXI_LIBRARIES_BUILT is clearer to > me as it the texinfo shared libraries are a direct dependency of the > code that may not use iconv directly. I agree that SHARED_TXI_LIBRARIES_BUILT (or whatever it's called) would be better at expressing this dependency than HAVE_ICONV. > I may be missing something, but doesn't that mean that in some cases, we > would have constructs like > > if HAVE_ICONV > if BUILD_C_CODE > ... > endif > endif > > instead of simply (since the condition is determined once for all in > configure): > if BUILD_C_CODE > ... > endif I guess possibly you'd need them both in some cases as they express different things. > > > To me the DISABLE_XS and BUILD_C_CODE conditions are logical: gnulib is > > > used directly by some XS modules and is also needed by the C libraries. > > > > When I see the following in tta/perl/XSTexinfo/Makefile.am: > > > > if BUILD_C_CODE > > xs_LTLIBRARIES += DocumentXS.la > > endif > > > > - the obvious implication is that DocumentXS.la is "C code" that should > > only be built if we are building C code. > > Is it based on the name of the conditional, or something deeper about > the conditional? The name of the condition. The condition controls whether something is built, and has "build" in its name. It's easy to draw the conclusion that links the two. > > You are viewing it a different way, which would be hard for anybody to > > infer: the object DocumentXS.la *depends* on a category of C library that > > you consider to be "C code" - but the object is not itself considered > > to be, necessarily, C code. > > > > Hopefully it's fairly easy for you to see how confusion could arise here. > > I see that the name is not so good, but even with this name, I do not > fully see the confusion, as the fact that the object is C code seems to > be quite clear irrespective of the conditional existence (or name). But > I may be missing something. Yes, but in your view "BUILD_C_CODE" was not for controlling whether XS modules were built. XS modules are C code, but not the kind of C code governed by the condition (MiscXS and XSParagraph were not governed).
