On Mon, Feb 02, 2026 at 10:18:28PM +0100, Patrice Dumas wrote: > On Mon, Feb 02, 2026 at 09:02:58PM +0000, Gavin Smith wrote: > > On Mon, Feb 02, 2026 at 09:35:28PM +0100, Patrice Dumas wrote: > > > I propose to change to the following: > > > > > > SUBDIRS = > > > > > > if BUILD_C_CODE > > > SUBDIRS += gnulib/lib > > > else > > > if ! DISABLE_XS > > > SUBDIRS += gnulib/lib > > > endif > > > endif > > > > > > > I find having both the DISABLE_XS and BUILD_C_CODE conditions confusing. > > gnulib, XSParagraph.la and MiscXS.la are C code, so you would naively > > expect them to not to be built if BUILD_C_CODE is false. That's what > > I thought the point of the conditional was. > > Maybe we should change the name of the conditional, then, for example to > BUILD_C_LIBRARIES?
XS modules are still a C library. I thought the removal of the HAVE_ICONV conditional was supposed to be a simplification, but it seems not to be, if we still have different objects being built depending on the setting thereof. Before, we had the DISABLE_XS condition and the HAVE_ICONV condition. Currently, we have BUILD_C_CODE and DISABLE_XS which, as far as I understand, interact so to produce the same results (but in a more obscure way). If we we want the HAVE_ICONV check to still only to apply to certain XS modules, then my preference would be to reinstate the HAVE_ICONV conditionals as they were, and make BUILD_C_CODE the overriding conditional that is not dependent on HAVE_ICONV. So we'd get rid of the 'if test "x$am_func_iconv" = "xyes"' check in tta/configure.ac and put back all the "if HAVE_ICONV" conditions in tta/perl/XSTexinfo/Makefile.am (that were changed to "if BUILD_C_CODE"). > 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. 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 expect there is some combination of features or configure checks where > > it makes sense to build XSParagraph.la and MiscXS.la but not the other > > XS modules, but what that combination is is not at all obvious to me. > > > > You add gnulib for the case when BUILD_C_CODE is false and DISABLE_XS > > is also false. As far as I can see from the following in tta/configure.ac, > > this is only the case when iconv is not available. Is that the case you > > were thinking of or was it something else? > > Yes, it is the case that can happen in practice (and happens for > macos-26). But my reasoning was not related to iconv, rather, as I said > above, to the fact that gnulib is used directly by some XS modules and > so should be built if ! DISABLE_XS, and gnulib is also needed by the C > libraries, and so should also be built if BUILD_C_CODE/BUILD_C_LIBRARIES > is set. > > > build_C_code=no > > if test "x$am_func_iconv" = "xyes"; then > > test "z$enable_xs" = zyes && build_C_code=yes > > test "z$enable_additional_tests" = zyes && build_C_code=yes > > test "z$with_swig" = zyes && build_C_code=yes > > fi > > > > AM_CONDITIONAL([BUILD_C_CODE], [test "z$build_C_code" = zyes]) > > AC_SUBST([build_C_code]) > > > > > > -- > Pat
