Johnny Rosenberg wrote:
> What is the reason that libFLAC is available for Windows in the first
> place? Aren't there lots of alternatives for Windows anyway?
FLAC is valuable because you can create a FLAC file on any platform
and play it back on any platform. Thats why we support Windows.
Erik
Hi,
In article <513644f0.7030...@thaumas.net>,
Ralph Giles wrote:
> On 13-03-05 10:50 AM, Andy Hawkins wrote:
>
>> Yes, all CMake does is generate the files appropriate for your build system
>> (Makefiles for linux, Visual Studio project files for Windows).
>
> I meant that CMake cannot
On 13-03-05 10:50 AM, Andy Hawkins wrote:
> Yes, all CMake does is generate the files appropriate for your build system
> (Makefiles for linux, Visual Studio project files for Windows).
I meant that CMake cannot generate Visual Studio project files for
Windows without an actual Windows environmen
What is the reason that libFLAC is available for Windows in the first
place? Aren't there lots of alternatives for Windows anyway?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Hi,
In article <51362d2f.4070...@thaumas.net>,
Ralph Giles wrote:
> Does this still require a Visual Studio install? If so this feature
> isn't much help for developers based on non-Windows systems.
Yes, all CMake does is generate the files appropriate for your build system
(Makefiles
On 13-03-04 12:05 PM, Andy Hawkins wrote:
> Not sure if you've considered it, but cmake allows you to generate Visual
> Studio project files automatically, while still allowing cross platform
> builds.
Does this still require a Visual Studio install? If so this feature
isn't much help for develop
Hi,
In article <5135935c.7070...@opensuse.org>,
Cristian Rodríguez wrote:
> On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote:
>
>> May look at CMake after this current release.
>
> That will make the situation reverse, that is, better for windows,
> insane for the rest of the world.
On Sun, 3 Mar 2013 18:30:08 -0500
"Ben Allison" wrote:
> >> * change instances of uint32_t in bitwriter.c to FLAC__uint32
> >
> > Can we include to fix this instead?
>
> Sadly there is no inttypes.h on MSVC. At least versions to Visual
> Studio 2010. I presume this is why ordinal.h was create
Christoph Terasa wrote:
> When you say "FOSS/libre" you mean "GNU/Linux"?
No specifically I mean Linux, FreeBSD, OpenBSD, NetBSD, any other *BSD
as well as things like Haiku.
> I can imagine FOSS
> environments which don't rely on the GNU build system.
I can imagine them too, but I actually ca
On 3/5/2013 7:54 AM, Erik de Castro Lopo wrote:
> Cristian Rodríguez wrote:
>
>> On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote:
>>
>>> May look at CMake after this current release.
>> That will make the situation reverse, that is, better for windows,
>> insane for the rest of the world.
> *If*
Cristian Rodríguez wrote:
> On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote:
>
> > May look at CMake after this current release.
>
> That will make the situation reverse, that is, better for windows,
> insane for the rest of the world.
*If* I get around to it, it will be in a branch, not in
On 03/05/2013 03:32 AM, Erik de Castro Lopo wrote:
> May look at CMake after this current release.
That will make the situation reverse, that is, better for windows,
insane for the rest of the world.
___
flac-dev mailing list
flac-dev@xiph.org
http:/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05.03.2013 10:32, Erik de Castro Lopo wrote:
> Andy Hawkins wrote:
>
>> Hi,
>>
>> In article
>> <20130304070023.141c9f101622a34c46d68...@mega-nerd.com>, Erik de
>> Castro Lopo wrote:
project tends to be a pain unless one of the principal
Andy Hawkins wrote:
> Hi,
>
> In article <20130304070023.141c9f101622a34c46d68...@mega-nerd.com>,
>Erik de Castro Lopo wrote:
> >> project tends to be a pain unless one of the principal developers is using
> >> it on a daily basis (as I know you've experienced with libsndfile, Erik).
On Tue, 5 Mar 2013 07:21:49 +1100
Erik de Castro Lopo wrote:
> Ben Allison wrote:
>
> > Here's another go at it. I only have VS2008 and VS2010 to test
> > with right now. VS6.0, VS2003 and VS2005 are untested.
>
> Thanks for your work on this Ben.
Thanks also from the Audacity developers - th
Ben Allison wrote:
> Here's another go at it. I only have VS2008 and VS2010 to test with right
> now. VS6.0, VS2003 and VS2005 are untested.
Thanks for your work on this Ben.
> I would recommend using FLAC__uint32 instead of uint32_t to avoid these
> small #if _MSC_VER < things everywhere
Hi,
In article <20130304070023.141c9f101622a34c46d68...@mega-nerd.com>,
Erik de Castro Lopo wrote:
>> project tends to be a pain unless one of the principal developers is using
>> it on a daily basis (as I know you've experienced with libsndfile, Erik).
>
> Yes, painfully aware of this.
Here's another go at it. I only have VS2008 and VS2010 to test with right
now. VS6.0, VS2003 and VS2005 are untested.
I'm still not too happy with it, but it does work.
I would recommend using FLAC__uint32 instead of uint32_t to avoid these
small #if _MSC_VER < things everywhere, although
Ben Allison wrote:
> Visual Studio files (which don't use config.h, but define various things
> in the project settings) are compiling with the wrong FLAC version string
> (1.2.0 or 1.2.1)
>
> I've attached the patch.
Ben,
I'll apply this patch when all the other issues are sorted out. Thanks.
Ben Allison wrote:
> >> * change instances of uint32_t in bitwriter.c to FLAC__uint32
> >
> > Can we include to fix this instead?
>
> Sadly there is no inttypes.h on MSVC. At least versions to Visual Studio
> 2010. I presume this is why ordinal.h was created in the first place.
I'm not sure h
>> * change instances of uint32_t in bitwriter.c to FLAC__uint32
>
> Can we include to fix this instead?
Sadly there is no inttypes.h on MSVC. At least versions to Visual Studio
2010. I presume this is why ordinal.h was created in the first place.
I'll use the compat.h header for the __inline
Ben Allison wrote:
> There's a more few issues for compiling on MSVC. I put together a patch.
>
> Here's a quick rundown:
> * must use __inline keyword with static inline functions (bitmath.h)
If you include "share/compath.h" you will get a inline #defined as __inline
when _MSC_VER is defined.
There's a more few issues for compiling on MSVC. I put together a patch.
Here's a quick rundown:
* must use __inline keyword with static inline functions (bitmath.h)
* change instances of uint32_t in bitwriter.c to FLAC__uint32
* functions marked inline cannot be used within another C file (e.g.
Ben Allison wrote:
> Visual Studio files (which don't use config.h, but define various things
> in the project settings) are compiling with the wrong FLAC version string
> (1.2.0 or 1.2.1)
Is there really no other way to set the version string?
> I've attached the patch.
Thanks. I'm wondering i
Visual Studio files (which don't use config.h, but define various things
in the project settings) are compiling with the wrong FLAC version string
(1.2.0 or 1.2.1)
I've attached the patch.
Maintaining Visual Studio project files in a cross-platform open-source
project tends to be a pain unless on
Johnny Rosenberg wrote:
> Maybe a stupid question, but I was born stupid and I have walked that
> path ever since, so: Is there a changelog?
The only changelog is the git changelog. I will be writing a real
changelog to go in the actual release tarball before the official
release.
The git change
I don't know how it happened, but I accidently sent the message below
privately and not to the list. Maybe a result of my built in
stupidity.
-- Forwarded message --
From: Johnny Rosenberg
Date: 2013/3/3
Subject: Re: [flac-dev] flac 1.3.0pre1 prelease
To: Cristian Rodríguez
20
27 matches
Mail list logo
