bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63371] build fails on MinGW due to missing gnulib close module


From: Bruno Haible
Subject: [bug #63371] build fails on MinGW due to missing gnulib close module
Date: Wed, 21 Jun 2023 16:29:10 -0400 (EDT)

Follow-up Comment #7, bug #63371 (project gettext):


> the supported way is non-standard for MinGW and rather complicated to setup,
especially in any automated fashion

The problem with x86_64-w64-mingw32 in a build environment of type
x86_64-unknown-linux-gnu is that it adds another component, namely Wine, to
the mix. Which adds a source of complexity/bugs. And what is it worth if there
is the possibility that the resulting binaries work fine in this environment,
but not in real Windows?

> this may indicate problems on other platforms too. The point of using
Autoconf-based build system surely is to detect and handle runtime conditions
without having specific hard-coded support for specific platforms (e.g.,
require 2 POSIX-y runtimes to build for Windows), right? Similarly, the point
of gnulib is to provide missing bits in a more general fashion, no?

The Autoconf principle with configure tests works fine as long as the
behaviour differences are small (e.g. a parameter supporting a certain value
or not). Whereas for native Windows support, in many places, specific code is
needed. And then it makes no difference whether we use an Autoconf test or
just a specific 'case $host_os in mingw*) ...'. There is no continuum of
operating systems between POSIX and Windows. It's two isolated groups of OSes:
POSIX and Unix-like on one hand, and native Windows. It would be useless to
write "general" code that works on a continuum of operating systems that does
not exist. Because such code would not be testable, and code which isn't
testable is usually not working.

> That seems worth fixing regardless of anything else.

If you find it worth fixing, then feel free to spend the effort on it. I don't
want to spend effort on it, since there don't need to be several ways to
arrive at bative Windows binaries. I chose the way that seems most reliable to
me.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63371>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]