Re: error: 'unitypes.h' file not found

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