On Tue, Jan 27, 2026 at 11:48:50PM +0100, [email protected] wrote:
> On Tue, Jan 27, 2026 at 11:03:08PM +0100, [email protected] wrote:
> > On Tue, Jan 27, 2026 at 07:55:31PM +0000, Gavin Smith wrote:
> > > The main use case I am concerned about is when XS modules are disabled.
> > > Even if --disable-perl-xs is given to "./configure", a large amount of
> > > time
> > > is spent building dynamically linked libraries under the tta/ directory
> > > (including gnulib). This is pointless for users who are only going to
> > > use the pure Perl implementations. Is there no way to disable the C code
> > > being built under tta?
> >
> > Maybe if disable XS is set and --enable-additional-checks is not passed
> > we would not recurse in tta/C?
> >
> > As a side note, the SWIG python interface can be built with disable XS,
> > so it would need the same conditionals.
>
> After some thinking, maybe a possibility would be to recurse in C if
> either XS is enabled, --enable-additional-checks is passed or any SWIG
> interface is built, as SWIG interfaces may work and provide an
> interesting interface even if XS is disabled.
How does the following look?
diff --git a/tta/Makefile.am b/tta/Makefile.am
index 2133586853..375b873463 100644
--- a/tta/Makefile.am
+++ b/tta/Makefile.am
@@ -18,7 +18,11 @@ EXTRA_DIST =
######################## Gnulib ################################
-SUBDIRS = gnulib/lib
+SUBDIRS =
+
+if BUILD_C_CODE
+SUBDIRS += gnulib/lib
+endif
EXTRA_DIST += gnulib/m4/gnulib-cache.m4
@@ -34,12 +38,8 @@ $(srcdir)/Makefile.docstr: maintain/regenerate_docstr.sh \
&& $(SHELL) ./maintain/regenerate_docstr.sh Makefile.docstr
-if ! DISABLE_XS
+if BUILD_C_CODE
SUBDIRS += C
-else
-if HAVE_ICONV
-SUBDIRS += C
-endif
endif
SUBDIRS += . perl tests
diff --git a/tta/configure.ac b/tta/configure.ac
index fa8cbd682f..e71421c989 100644
--- a/tta/configure.ac
+++ b/tta/configure.ac
@@ -602,6 +602,16 @@ fi
AM_CONDITIONAL([SWIG_PERL_TESTS], [test "z$swig_perl_tests" = 'zyes'])
+build_C_code=no
+test "z$enable_xs" = zyes && build_C_code=yes
+
+if test "x$am_func_iconv" = "xyes"; then
+ 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([perlarchdir])
AC_SUBST([perllibdir])
(It's easier to set the conditional in shell in configure.ac than to use
nested Automake conditionals.)
It seems completely wrong that code the size of the C texi2any code
should block a successful build in cases when it is not used, as was the
case in some of the build failures reported by Bruno for texinfo-7.2.90
(e.g the "texinfo-7.2.90 on AIX" thread).
There is one more issue which is the amount of time spent to run
the configure checks (that mostly come from gnulib) under tta/.
In texinfo-7.2, the configure.ac file for texi2any C code was under
tp/Texinfo/XS. Now it is directly under tta/, along with its own gnulib
checkout.
Stopping the subsidiary configure script from running if texi2any C code
were disabled would require some reorganisation of the source tree,
perhaps moving tta/perl/XSTexinfo and tta/configure.ac under tta/C.
(Then we'd put the BUILD_C_CODE condition in the top-level configure.ac
etc.)
