[tex-k] c-auto.h files

[Peter Breitenlohner]

On Wed, 13 Jan 2010, Javier Múgica wrote:

>>> This remark may be for tlbuild: there are two c-auto.in, one in web2c/
>>> and another in kpathsea/. Their purpose is essentialy the same, so
>>> they should be merged in a single file, a fortiori because
>>> web2c/config.h includes both of them (one directly, the other via
>>> kpathsea/config.h) [hence cpascal.h also]
>
> Taco:
>
>> You will have to talk to Peter about that, but I suspect this is
>> because one of this used during the 'configuration' stage and the
>> other in the 'building' stage (which also runs some configure scripts)
>
> So I send it to you. If they cannot be merged they could at least be
> reduced to the minimum, say the version string and specific web2c
> feature in the one from web2c. All the header/compiler related defines
> could be placed in an c-auto.h file. ...

Hi Javier,

the two c-auto.in files in web2c/ and kpathsea/ are the (primary)
configuration header templates for these packages (i.e., subdirs),
automatically created by autoheader/autoconf and instantiated as c-auto.h by
configure (more conventionally they would be named config.h).  Thus I don't
see a practical way to reduce their contents.

I know that ideally each package should only include its own configuration
header, but for libraries that is not always possible (and for kpathsea it
is not).  However, that could only cause problems when building web2c/ with
installed kpathsea library and headers (yes that is possible although quite
unusual) and either using different compilers or using the same headers for
two architectures on bi-arch systems (e.g., Linux i686/x86_64, ppc/ppc64).

Otherwise having the same entries in both headers may be redundant but is
certainly harmless, the same entries being determined by the same configure
tests, i.e.,
   AC_CHECK_HEADERS([string.h]) => HAVE_STRING_h

==========

>From what you write below, I assume you build for Windows and don't/can't
run the configure scripts to generate the c-auto.h's from the corresponding
c-auto.in's.  I am certainly no expert in this area but I know that there
are ways to run the configure scripts also for Windows.

==========

> As I posted recently to the tlbuild list, WIN32 is not defined on
> recent version of the microsorf VC libraries, at least from 2003. So
> the test
>
> #if defined(_WIN32) || defined(_WIN32_WCE) || defined(__WIN32__)
> #  ifndef WIN32
> #    define WIN32
> #  endif
> #endif
>
> should be placed very soon, possibly in cpascal.h right after the
> #ifndef CPASCAL_H / #define CPASCAL_H. Note that what comes right
> after that now is precisely an #ifdef WIN32
>
>
> Also some cleaning might be needed, but that is less important to me
> right now. For example, in cpascal.h:
>
> #if defined (__DJGPP__) || defined (WIN32)
> #include <io.h>
> ...
> #endif
>
> but in kpathsea/config.h
>
> #ifdef __DJGPP__
> #include <fcntl.h>	/* for long filenames' stuff */
> #include <dir.h>	/* for `getdisk' */
> #include <io.h>	/* for `setmode' */
> #endif

A quite different topic: it is sad that one has to test for WIN32 or similar
as this is contradicts the autoconf philosophy.  All this could certainly be
cleaned up and/or improved (by someone familiar with all aspects of building
for Windows: MS compilers with or without MSYS/MINGW, gcc and Cygwin, cross
compilers, ...).

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>