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

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