[flac-dev] Lets work towards a new version

lvqcl lvqcl.mail at gmail.com
Wed Jun 18 18:00:39 PDT 2014

Erik de Castro Lopo wrote:

> It sees that the most serious bug in the flac bug tracker:
>     https://sourceforge.net/p/flac/bugs/413/
> has been fixed in git. This fix alone is worth a new release so its
> time to work towards one.
> Things I need to do for this new release:
> * Deal with all current patches on the mailing list.
> * Review all bugs reported against 1.3.0 on the sf.net.
> * Testing and coordination of testing across platforms and build systems.
> Anything else I've forgotten or people would like to see?

Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with
VC2005 Express and doesn't allow to build 64-bit files/libraries.

IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio
2012/2013 Express are free and allow to build 64-bit files.

VS 2005/2008 use .vcproj files, and VS 2010/2012/2013 use .vcxproj
and .vcxproj.filters files, so it's possible to have two sets of
MSVS solution files: one for 2005/2008 and another for 2010/2012/2013.

But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln
(or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?)

What do you think?

VC projects contain relative paths such as "..\..\include". Is it better to
leave them as is or to change to something like "$(SolutionDir)include"?

Currently there are two ia32 asm files (bitreader_asm.nasm and stream_encoder_asm.nasm)
that are unused and not necessary to compile libFLAC: they offer no speed benefit
and the corresponding functions were commented out (*after* the release of 1.3.0):


Is it better to remove these files from Makefile and .vcproj files, or to leave them?
I don't think that they will become useful again, but who knows...

More information about the flac-dev mailing list