[flac-dev] libFLAC, win_utf8_io, etc.

[lvqcl]

Evan Ramos wrote:

>> So currently libFLAC on _WIN32 does depend on win_utf8_io.
>
> Does my patch fix this issue on your end?

I don't use libFLAC, so it's not an *issue* for me. So I didn't test your patch.

Previously all win_utf8_io stuff was intended to be MSVC-only:
the use of win_utf8_io was controlled by FLAC__STRINGS_IN_UTF8 preprocessor
macro (which was defined only in MSVC *.vcproj files) but then it was replaced
by simple _WIN32 (in the commit "Enable utf8 I/O stuff when compiling with MinGW",
<https://git.xiph.org/?p=flac.git;a=commitdiff;h=2199d086921eb37d249cae0731f334556ec6209d>)


>> BTW, share/compat.h includes share/win_utf8_io.h (if _WIN32 is defined),
>> and is included into many libFLAC source files. As a result, some libFLAC
>> source files unnecessarily include share/win_utf8_io.h, windows.h, etc.
>
> It looks like win_utf8_io.h only includes windows.h in order to have
> the proper types to declare CreateFile_utf8, which is used in
> src/flac/decode.c and src/share/grabbag/file.c. I suppose those two
> files could #define FLAC__INCLUDE_WINAPI and win_utf8_io.h could guard
> the include and CreateFile_utf8 declaration with it, if we wanted to
> avoid windows.h. If we wanted to avoid share/win_utf8_io.h completely,
> we would need to do something similar in the 34 files that use
> flac_(printf|fprintf|vfprintf|fopen|chmod|utime|stat|unlink|rename),
> which would be counterproductive to the purpose of compat.h.

Another idea: it's possible to have share/compat_lib.h that doesn't
include win_utf8_io.h and doesn't have definitions of *_utf8 functions
and share/compat.h that includes share/compat_lib.h, share/win_utf8_io.h
and defines all *_utf8 functions.
Source files outside libFLAC use share/compat.h, and libFLAC sources
include only share/compat_lib.h (and share/win_utf8_io.h when necessary).


> On the topic of header minimalism, we may want to #define
> WIN32_LEAN_AND_MEAN and NOGDI before every #include <windows.h> in the
> codebase.

Maybe, although I'm not sure that it will noticeably reduce compile time.