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?) _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
