[flac-dev] Lets work towards a new version

[lvqcl]

Erik de Castro Lopo wrote:

>> 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?
>
> I think having 64 bit builds on Windows would be a good thing. Unfortunately
> since I don't have *any* Windows machines to even test on, zero recent
> experience on Windows and little desire to reaquaint myself with Windows
> this is not a job for me. However, I am more than happy to have someone
> else undertake this task, and will help where I can.
>
> As for what versions of MSVC we should support, I am not really
> qualified to say. What do other similar projects do? Eg Audacity?

Audacity still uses VS2008 and slowly tries to migrate to VS2012.
But as stated at <http://wiki.audacityteam.org/wiki/Developing_On_Windows>,
"Audacity is currently a 32-bit only application". So it doesn't need
64-bit builds.
Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008
and 'audacity-vs2012_EXPERIMENTAL.sln' made with Visual Studio Express 2012 for Windows Desktop.



> My main concern about having multiple build systems is the maintenance
> burden. As long as that burden is minor I'm happy to accept what people
> are willing to contribute. I personally will support the autotools based
> build system and can also support the Makefile.lite build system.

That's why I asked about unused .nasm files: it's better to do all the
changes to .vcproj files first, and only then convert them to .vcxproj.



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

I opened libFLAC_static.vcproj in a text editor and it turns out that it
contains relative paths anyway:
     <File RelativePath="..\..\include\FLAC\stream_encoder.h"></File>
So replacing relative paths in "AdditionalIncludeDirectories" entries seems
rather pointless, sorry.



>> 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...
>
> I think they should be deleted in a commit that says something like "Removing
> old nasm versions of some functions". That will clearly mark that commit so
> that if needed the files can be easily retrieved from the Git history.

Should these patches also remove those .nasm files from the source tree or not?
(currently src/libFLAC/ia32 folder contains unused lpc_asm-unrolled.nasm
file, so why remove unused bitreader_asm.nasm and stream_encoder_asm.nasm files?)