Re: Avoid gnulib redefinitions - MDA

[Bruno Haible]

Hi Gavin,

> Previously in the Texinfo project, we added variables to configure.ac to
> stop the redefinition of "Microsoft deprecated aliases":
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00004.html
> 
> For example, GNULIB_MDA_FDOPEN to stop the redefinition of 'fdopen'.
> 
> Recently, it was reported that this didn't work when building on
> MS-Windows.  I found that it should maybe be GL_GNULIB_MDA_FDOPEN instead:
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00180.html
> 
> I had identified the following change as potentially being responsible:
> 
> 2021-04-11  Bruno Haible  <bruno@clisp.org>
> 
>         Support several gnulib-tool invocations under the same configure.ac.
>         Reported by Reuben Thomas <rrt@sc3d.org> in
>         
> <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00104.html>.  
>         This is done by defining the Gnulib module indicator variables per
>         gnulib-tool invocation. So that a generated .h file is no longer
>         influenced by the set of modules used in other gnulib-tool 
> invocations. 
>         * gnulib-tool (func_compute_include_guard_prefix): Set
>         module_indicator_prefix.
> 
> Should we use the variables with the GL_ prefix now and is this something
> we can rely on?  Or should we simply #undef fdopen and the other symbols?

The way to avoid a particular MDA symbol definition (GNULIB_MDA_FDOPEN=0
before April 2021, GL_GNULIB_MDA_FDOPEN=0 after April 2021) is an undocumented
functionality. It is not expected that it will break soon. The 2021-04-11
change that you cited above was a once-in-a-decade change. But it may break
theoretically, since it is not in the form of a stable functionality.
(A stable, supported functionality would be something like a gnulib-tool
option and/or a module name.)

> We don't use fdopen, putenv or mktemp in the library being built, but these
> are pulled in by Gnulib dependencies.
>
> I don't know if it is possible at all but it would seem to be better
> for Gnulib not to redefine symbols that are not actually used in the
> program.

I chose not to do so for the following reasons:

  * These "Microsoft deprecated aliases" are deprecated. This means, they
    can break at any moment, causing bug reports regarding all released
    tarballs. It is better (for 99% of the package maintainers) to have
    this problem dealt with, in advance, _before_ it becomes an FTBFS.

  * Already now, these "Microsoft deprecated alias" symbols cause link
    errors in a particular native Windows platform. Namely, when clang-cl
    is used in combination with the MSVC header files. (clang for Windows
    does not come with its own Win32 API header files, like mingw does.)

  * There are 50 "Microsoft deprecated aliases". If Gnulib would use an
    opt-in approach for these, i.e. if the package maintainer would have
    to enumerate all of these that their package uses one-by-one, it
    would be too much maintenance effort / too high risk of mistake.

  * Given that in this list you find symbols like 'open' / 'creat' / 'close'
    and 'strdup', most programs that rely on POSIX APIs need the
    "Microsoft deprecated aliases" handling. Only programs that use only
    ISO C APIs wouldn't care; but these programs usually don't need Gnulib
    anyway.

So, to me, an opt-out approach seems to be the best approach here.

It broke because the hint that I gave you in March 2021 was not a stable API.
But we don't have stable APIs for everything.

Bruno