Re: [flac-dev] Lets do a 1.3.2 release

On 8 January 2016 at 11:56, Erik de Castro Lopo wrote: > I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot. Yes, great idea! This is an active

Re: [flac-dev] Lets do a 1.3.2 release

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

[flac-dev] [PATCH] for flacdiff

Fixes are similar to parts of the following commits: flacdiff.patch Description: Binary data

Re: [flac-dev] Lets do a 1.3.2 release

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

[flac-dev] libFLAC, win_utf8_io, etc.

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

[flac-dev] About libFLAC -> win_utf8_io dependency

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

Re: [flac-dev] Lets do a 1.3.2 release

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

[flac-dev] flac, UTF-8 and Windows

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

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

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

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

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

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

lvqcl wrote: > At least I have a suggestion: to enclose all FLAC API functions that > take char* filename argument into > > #ifndef FLAC__FILENAME_API_DISABLED ... #endif Sorry, it wasn't clear: I mean -- to enclose all declarations of such functions in FLAC/*.h and FLAC++/*.h header files.

Re: [flac-dev] Lets do a 1.3.2 release

On 01/08/16 02:56 AM, Erik de Castro Lopo wrote: HI all, I think its time for a new release. The current code base is stable and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been building regularly on their

Re: [flac-dev] Lets do a 1.3.2 release

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. -- Janne On 9.1.2016 5.08, Evan