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? 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. > 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
