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 2014-06-19 6:01 AM, Erik de Castro Lopo wrote:> 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.FWIW, the other xiph codecs have parallel sets of MSVC project files under the win32 directory. We did this because while newer versions can generally open/update older project files, the reverse is true and many developers said they weren't upgrading. libogg has separate project files for VS2003, VS2005, VS2008, VS2010, and VS6. That said, for Opus we've only been maintaining VS2010 project files (tested with both VS2010 and VS2013 Express) and haven't had any complaints. I'd suggest a single set of project files which work with a previous but recent release of the free Visual Studio Express, and see if that works for people. -r
Ralph Giles <giles at thaumas.net> ?????(?) ? ????? ?????? Thu, 19 Jun 2014 17:15:27 +0400:> FWIW, the other xiph codecs have parallel sets of MSVC project files > under the win32 directory. We did this because while newer versions can > generally open/update older project files, the reverse is true and many > developers said they weren't upgrading. > > libogg has separate project files for VS2003, VS2005, VS2008, VS2010, > and VS6.MSVS 2005 project for libogg contains 2 *.vcproj files in a win32/VS2005 folder. In FLAC, there are 27 *.vcproj files scattered all over its source tree. It's a complicated task to move them into one separate folder.> That said, for Opus we've only been maintaining VS2010 project files > (tested with both VS2010 and VS2013 Express) and haven't had any > complaints. I'd suggest a single set of project files which work with a > previous but recent release of the free Visual Studio Express, and see > if that works for people.VS 2010/2102/2013 project files are forward and backward compatible. But it's not possible to open them with older versions such as VS2005 and VS2008, and unfortunately there are developers that still use these versions.
Erik de Castro Lopo <mle+la at mega-nerd.com> ?????(?) ? ????? ?????? Thu, 19 Jun 2014 17:01:26 +0400:>> (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.Well, lpc_asm-unrolled.nasm exists only in Git but not in any of release tarballs. And there are no significant changes for it since Jun'2001. Anybody knows its purpose?
lvqcl wrote:> Erik de Castro Lopo <mle+la at mega-nerd.com> ?????(?) ? ????? ?????? Thu, 19 Jun 2014 17:01:26 +0400: > > >> (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. > > Well, lpc_asm-unrolled.nasm exists only in Git but not in any of release tarballs. > And there are no significant changes for it since Jun'2001. Anybody knows its purpose?Nope! June 2001 is over a decade before I became maintainer :-). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/