similar to: test_streams dependencies

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

test_streams doesn't create/open files with non-ascii filenames, so there's no need in unicode support. The patch changes flac_fopen() calls to fopen(), and removes dependency of test_streams from win_utf8_io. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_streams.zip Type: application/zip Size: 2445 bytes Desc: not available Url :

My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). You could simply have the following: #if defined _MSC_VER || defined __MINGW32__ #define flac_fopen fopen #endif In a header, or simply at

Ah, ok. I was thinking along the lines of FLAC__int32, where the intention is to be portable without depending upon any specific system. I assumed that flac_fopen() came from that design pattern. If it's really only a few years old, and not original, then changing it back should be fine. A bigger question might be: how are file opens handled in most flac code? It's probably best for

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

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

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

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: > 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

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

lvqcl wrote: > When I compile flac project with MSYS/MinGW-w64, I can see two files: > libFLAC.a and libFLAC-static.a. The only difference between them > is that libFLAC.a contains functions from win_utf8_io. > But 'make install' adds libFLAC.a into /local/lib, not libFLAC-static.a. Thank you for checking this. I've always had trouble with Autotools on Windows, even when

src/test_streams/main.c fails under MSVC because it doesn't provide snprintf(). The patch replaces snprintf() with flac_snprintf(). -------------- next part -------------- A non-text attachment was scrubbed... Name: test_streams.patch Type: application/octet-stream Size: 486 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20150223/b0908a26/attachment.obj

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 -

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

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work

The patch changes flac_snprintf (in src/share/grabbag/snprintf.c) and its copy local_snprintf (src/libFLAC/metadata_iterators.c). It also adds flac_vsnprintf (src/share/grabbag/snprintf.c) and its copy local_vsnprintf (src/share/win_utf8_io/win_utf8_io.c). And it changes stats_print_info in src/flac/utils.c so it uses flac_vsnprintf instead of vsnprintf. Return value checking becomes

That enables an special implementation that checks for common memory errors and will save us from a lot pain. --- test/test_bins.sh | 2 ++ test/test_flac.sh | 2 ++ test/test_grabbag.sh | 2 ++ test/test_libFLAC++.sh | 2 ++ test/test_libFLAC.sh | 3 +++ test/test_metaflac.sh | 2 ++ test/test_seeking.sh | 2 ++ test/test_streams.sh | 2 ++ 8 files

/share/compat.h includes win_utf8_io.h which in turn includes windows.h. But only flac/decode.c and share/grabbag/file.c need it. It was suggested earlier to guard this include by some #ifdef. I tried it, and it brokes compilation of some files because of missing includes. Imho it makes sense to fix this regardless whether the inclusion of windows.h inside win_utf8_io.h will be changed or not.

Those checks account for compiler changes/improvements introduced in Visual Studio 2010 that are not present in Visual Studio 2008. I will grab Visual Studio 2012 off of MSDN and make sure everything is OK there. -Ben > Hi Ben, > > Can you please remove the _MSC_VER >= 1600 check? > > _MSC_VER 1600 is set for Visual Studio 2010, which means > that Visual Studio 2012 will

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------