flac dev - Jul 2014 - [PATCH 1/3] removing asm version of precompute_partition_info_sums

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

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

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/