lvqcl wrote:> 1) > 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?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? 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.> 2) > 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.> 3) > 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): > > http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 > http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 > > 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. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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?)
lvqcl wrote:> 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.Ok, Audacity is not a good example to follow. We need to find out what some other common used cross platform project is doing. Preferably more than one project.> > 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.+1> >> 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.Ok, you know more about this than me.> >> 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?Yes.> (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?)I don't see any point in keeping files in release tarballs or in Git that provide no value. Documentation provides value, but unused source code does not. All the various build system files should be cleansed of references to these files and then we need a single commit that removes them. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On Thu, 19 Jun 2014 15:41:21 +1000 Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> lvqcl wrote: > > > 1) > > 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? > > I think having 64 bit builds on Windows would be a good thing.[...]> 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 is still only building 32-bit windows binaries, and officially with Visual Studio 2008 at the moment (for XP support amongst other things at the last release). However we are moving towards VS2012 being the "official" windows tool chain, and some people are already using it for development. This probably won't happen for the next release, but might for the one after, and I think needs to ahead of updating wxWidgets from 2.8 to 3.0 (which is probably on a similar time scale). Richard
lvqcl
2014-Jul-04 12:36 UTC
[flac-dev] [PATCH 1/3] removing asm version of precompute_partition_info_sums
Erik de Castro Lopo wrote:>> 3) >> 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): >> >> http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 >> http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 >> >> 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.This patch removes unused FLAC__precompute_partition_info_sums_32bit_asm_ia32_(). -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_stream_encoder_asm.patch Type: application/octet-stream Size: 10453 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140704/92c103c8/attachment-0001.obj
Erik de Castro Lopo
2014-Jul-06 10:24 UTC
[flac-dev] [PATCH 1/3] removing asm version of precompute_partition_info_sums
lvqcl wrote:> Erik de Castro Lopo wrote: > > >> 3) > >> 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): > >> > >> http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 > >> http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 > >> > >> 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. > > > This patch removes unused FLAC__precompute_partition_info_sums_32bit_asm_ia32_().Applied. Thanks. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/