similar to: [PATCH] remove libFLAC dependency of win_utf8_io

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The set of four patches that remove dependency of libFLAC on win_utf8_io. >> >> Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite) >> >> Please review, especially makefile patches, I'm not very familiar with them. > > Applied. All good. Thanks. But the 1st patch

Erik de Castro Lopo wrote: > When I tried apply that patch, all but one hunk succeeded. I inspected > the rejected part, but that seemed to have already been applied. '1_sources.patch' creates windows_unicode_filenames.h and windows_unicode_filenames.c files that don't exist in the current git. > Lets just get a patch that fixes what we have now. Here it is: the missing

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share:

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

lvqcl wrote: > But it requires somebody to rewrite FLAC apps. At least I have a suggestion: to enclose all FLAC API functions that take char* filename argument into #ifndef FLAC__FILENAME_API_DISABLED ... #endif and maybe also all functions that take FILE* argument into #ifndef FLAC__FILEPTR_API_DISABLED ... #endif Then try to compile flac.exe/metaflac.exe/etc with

Janne Hyv?rinen wrote: > Win_utf8 stuff should not be included in libflac since it's only to be > used by the flac.exe frontend. It is not needed by other programs nor > would they benefit from it without doing the extra work of converting > their ansi filenames and functions to utf-8. > >> Version 2 of my patch attached, which fixes the problem for the >>

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes

This patch changes win_utf8_io.c: simplifies *print functions, improves file related functions and prepates to move all file related functions into libFLAC. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_io.patch Type: application/octet-stream Size: 14476 bytes Desc: not available Url :

Currently it is required to include share/compat.h before inclusion of share/win_utf8_io.h. That's because of print_console() declaration: its 3rd argument have type 'uint32_t' which is defined in share/compat.h. So share/win_utf8_io.h depends on share/compat.h which in turn includes share/win_utf8_io.h. Not a problem but it's a bit ugly imho. Actually, the 3rd argument of

lvqcl wrote: > IIRC libFLAC.a built with "./autogen.sh && ./configure && make" > contains all functions from win_utf8_io. So I think it's possible > to change some Makefile.lite or maybe build/*.mk files so that > there will be no need to add -lwin_utf8_io to -lFLAC. Version 2 of my patch attached, which fixes the problem for the Makefile.lite and Visual

I noticed that share/win_utf8_io.h includes windows.h anyway, so another include in win_utf8_io.c is unnecessary. Also, the comment there is incorrect. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_io.patch Type: application/octet-stream Size: 423 bytes Desc: not available Url :

Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) > CCLD utf8/libutf8.la > CC win_utf8_io/win_utf8_io.lo > win_utf8__io/win_utf8_io.c:266:13: error: static declaration > of 'set_filename_utf8' follows

lvqcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently

Erik de Castro Lopo wrote: >> Currently functions in win_utf8_io.c are a compatibility layer for >> libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC. > > Ok, lets do it. I just thought that it's more complicated. All *file* functions should really be moved to libFLAC. But other functions should not, because libFLAC doesn't use them. Two of them -

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avoid this dependency by replacing flac_fopen() with fopen(). test_streams doesn't open/create

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple

All MSVC projects that generate .lib files have '_static' suffix in their names; all but win_utf8_io. This patch renames it so that it follows this naming convention. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_static.patch Type: application/octet-stream Size: 9097 bytes Desc: not available Url :

lvqcl wrote: > Then IMHO all three build systems (configure && make, Makefile.lite > and MSVC) should be synchronized with each other +1 > TO ERIK: > > I have some patches, but they either modify MSVC .vcxproj files, > or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos. > So should they be applied? rejected? postponed until after flac 1.3.2? We

Evan Ramos wrote: >> So currently libFLAC on _WIN32 does depend on win_utf8_io. > > Does my patch fix this issue on your end? BTW, your patch also changes MSVC solution/projects. What's the problem with them? I built flac/metaflac/libFLAC libraries with Visual Studio many times, and haven't noticed anything wrong.