RE: Questions: ./config.h.in & ./windows-NT/config.h.in

[Conrad T. Pino]

Hi Derek,

> From: Derek Robert Price
> 
> Actually, if should be pretty straightforward, not in depth at all.
> Mostly, config.h.in undefines things that might later be defined, for
> reference and to get defines near their comments later.  The current
> windows-NT/config.h.in could even be used to create the template.  The
> algorithm, assuming the contents of the current windows-NT/config.h.in
> were in windows-NT/config.h.in.in would be something like:
> 
> copy config.h.in to windows-NT/config.h.in
> foreach #define in windows-NT/config.h.in.in
>     find corresponding #undef in windows-NT/config.h.in
>        (if not present, print warning)
>     replace line with current #define
> end foreach
> foreach #undef in config.h.in
>     find corresponding #define or #undef in windows-NT/config.h.in.in
>        (if not present, print warning)
> end foreach
> 
> The second loop, of course, could be sped up by caching the contents
> of windows-NT/config.h.in.in during the first loop.
========================================
OK, the concept looks sound but there are problems in "./config.h.in"
that IMO can be worked out.
--------------------
This is a good example that needs elaboration:

        /* ... */
        #undef FILESYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR

        #if FILESYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX
        # define FILESYSTEM_PREFIX_LEN(Filename) \
          ((Filename)[0] && (Filename)[1] == ':' ? 2 : 0)
        #else
        # define FILESYSTEM_PREFIX_LEN(Filename) 0
        #endif

IMO conditional #define warrants special attention along the lines of
"windows-NT/config.h.in.in" saying something about

        FILESYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR

but nothing about

        FILESYSTEM_PREFIX_LEN

which would be copied as is.

This means we must detect, track and copy (with contents):

        #if
        #ifdef
        #ifndef
        #endif

accurately which is doable provided Automake doesn't
get too wild with it's output.

What would you propose in this case?
--------------------
This is a good example that begs a question and I quote:

        /* Define to 1 if you have the `__secure_getenv' function. */
        #undef HAVE___SECURE_GETENV

        #if FILESYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR
        # define ISSLASH(C) ((C) == '/' || (C) == '\\')
        #else
        # define ISSLASH(C) ((C) == '/')
        #endif

Where are the comments and #define/#undef for

        FILESYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR

macro?

How should the script behave?
--------------------
This is one of multiple examples:

        /* ... */
        #ifndef _ALL_SOURCE
        # undef _ALL_SOURCE
        #endif

My initial thought is copy conditional blocks as is but
this seems to indicate something else is called for.

What would you propose in this case?
--------------------
Variation similar to last case:

        /* ... */
        #ifndef __cplusplus
        #undef inline
        #endif

What would you propose in this case?
========================================
Current "windows-NT/config.h.in" which I assume becomes the new
"windows-NT/config.h.in.in" has special stuff and examples follow.
--------------------
Cases were #define maps to function with the prototype:

        /* Under Windows NT, mkdir only takes one argument.  */
        #define CVS_MKDIR wnt_mkdir
        extern int wnt_mkdir (const char *PATH, int MODE);
        #define CVS_STAT wnt_stat
        extern int wnt_stat ();
        ...
--------------------
Cases of function prototype without #define macro:

        /* This function doesn't exist under Windows NT; we
           provide a stub.  */
        extern int readlink (char *path, char *buf, int buf_size);
--------------------
Cases where #define is conditional but not in ".." version:

        /* ... */
        #ifndef EDITOR_DFLT
        #define EDITOR_DFLT     "notepad"
        #endif

which IMO is trivial but let's remove all doubt.
========================================
IMO a final solution looks more like:

1. your proposal taking into account the special cases noted above
where "windows-NT/config.h.in.in" contains only overrides to what
is contained in "./config.h.in" with warnings issued as proposed
then followed by

2. appending special stuff to output where special stuff source is
requires further definition.

IMO script implementation is usable for any build with Windows as
the first candidate to benefit.  If true then let's examine why
Windows build is the only build with a "config.h.in" file.
========================================
> Derek

Conrad