Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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* I get around to it, it will be in a branch, not in mainline. I see FLAC as FOSS/libre software. It is firmly targeted at FOSS/libre operating systems and it if runs on others I'm fine with that, I'll even do what I can to help. However, I would not accept or force changes that make things worse for the FOSS world in favor of the rest. Erik When you say FOSS/libre you mean GNU/Linux? I can imagine FOSS environments which don't rely on the GNU build system. Also isn't making FLAC build equally nice and easy on all target platforms a worthwhile aim? This will make contributions from Mac OS or Windows users more likely, ultimately improving the project as a whole (e.g. the windows Unicode issue). Christoph ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 cannot name any. If you know of any I'd love to be enlightened. Also isn't making FLAC build equally nice and easy on all target platforms a worthwhile aim? FLAC is FOSS/libre and FOSS/libre will always be best supported, mainly because I can download the OS for free (as in no money) and install it in a free VM (like kvm or Qemu). As soon as its a you have to pay us money OS, its immediately harder for me to support. This will make contributions from Mac OS or Windows users more likely, ultimately improving the project as a whole (e.g. the windows Unicode issue). Well first off, lets be honest. Supporting Mac is trivially easy in comparison to support Windows. From the point of view of a library and command line program like flac, Mac is pretty much POSIX compliant. The Mac command line tools are not totally compatible with the GNU versions but there's usually a work around. For example this patch: https://git.xiph.org/?p=flac.git;a=commit;h=0432b9649071814ee462743528ad4f2bcc68408c As maintainer of FLAC, I have never rejected any sane patch from a Windows or Mac developer. I will push back until the patch is right (as I am currently doing with Ben Allison's MSVC patches) but that makes the code better and should eventually get the code into flac. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
On Sun, 3 Mar 2013 18:30:08 -0500 Ben Allison ben...@winamp.com wrote: * change instances of uint32_t in bitwriter.c to FLAC__uint32 Can we include inttypes.h 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. Visual Studio 2010 does include a stdint.h, however. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
Hi, In article 5135935c.7070...@opensuse.org, Cristian Rodríguezcrrodrig...@opensuse.org 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. I'm not sure why that should be the case. I maintain a (admittedly, fairly trivial) library that's built using CMake without any real issues at all, and its primary target is linux-like OSs (but it does work on Mac and Windows). Andy ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
Hi, In article 51362d2f.4070...@thaumas.net, Ralph Gilesgi...@thaumas.net 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 for linux, Visual Studio project files for Windows). You can often use the free 'Express' versions of the compilers to build with. Andy ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 I completely understand the desire to use C99 types. I've only done libFLAC, because I'm not as familiar with the rest of the codebase. But I will make another pass today with the other library and binaries. Thanks! YOu may also want to add the stdint.h style typedefs to that same file. flac-1-3-0-MSVC.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
Hi, In article 20130304070023.141c9f101622a34c46d68...@mega-nerd.com, Erik de Castro Lopomle...@mega-nerd.com 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. I'll be relying on others to keep the VS project files up-to-date. Not sure if you've considered it, but cmake allows you to generate Visual Studio project files automatically, while still allowing cross platform builds. Andy ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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, although I completely understand the desire to use C99 types. If we add _MSC_VER guarded definitions of the C99 type we need to include/share/compat.h then we should need the little #ifdefs everywhere. My general rules for this is: a) If its in the public header file don't mess with it too much (your MSVC changes to use __intXX are fine). b) If its code internal to the library use C99 type is possible. c) If its internal to the library and i needs tweaking for a particular compiler, add it to include/share/compat.h and include that header where needed. I've only done libFLAC, because I'm not as familiar with the rest of the codebase. But I will make another pass today with the other library and binaries. Great, thanks! Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
On Tue, 5 Mar 2013 07:21:49 +1100 Erik de Castro Lopo mle...@mega-nerd.com 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 - this being done upstream will make updating Audacity builds (done all with VS2008 express) to use the new release a lot easier. Richard ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
Andy Hawkins wrote: Hi, In article 20130304070023.141c9f101622a34c46d68...@mega-nerd.com, Erik de Castro Lopomle...@mega-nerd.com 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. I'll be relying on others to keep the VS project files up-to-date. Not sure if you've considered it, but cmake allows you to generate Visual Studio project files automatically, while still allowing cross platform builds. May look at CMake after this current release. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 mainline. I see FLAC as FOSS/libre software. It is firmly targeted at FOSS/libre operating systems and it if runs on others I'm fine with that, I'll even do what I can to help. However, I would not accept or force changes that make things worse for the FOSS world in favor of the rest. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of this repo. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 one of the principal developers is using it on a daily basis (as I know you've experienced with libsndfile, Erik). -Ben Allison 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 changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of this repo. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev 0001-update-VERSION-string-to-1.3.0-in-Visual-Studio-proj.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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 if it really should be 1.3.0 and not 1.3.0pre1 which is more accurate at least for now. Maintaining Visual Studio project files in a cross-platform open-source Quite honestly I'm a little surprised it worked at all :-). 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. I'll be relying on others to keep the VS project files up-to-date. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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. FLAC__bitreader_get_input_bits_unconsumed produces the linker error error LNK2001: unresolved external symbol _FLAC__bitreader_get_input_bits_unconsumed). This change has performance implications! I'd like someone to review this and possibly come up with a better solution. 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 changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of this repo. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev 0001-MSVC-compatibility-fixes.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
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. I'd prefer a single diffinition of that in one
place and one place only.
* change instances of uint32_t in bitwriter.c to FLAC__uint32
Can we include inttypes.h to fix this instead?
* functions marked inline cannot be used within another C file (e.g.
FLAC__bitreader_get_input_bits_unconsumed produces the linker error error
LNK2001: unresolved external symbol
_FLAC__bitreader_get_input_bits_unconsumed). This change has performance
implications! I'd like someone to review this and possibly come up with a
better solution.
The solution there is to move the function definition to the header file as
a static inline function
static inline unsigned FLAC__bitreader_get_input_bits_unconsumed(const
FLAC__BitReader *br)
{
return (br-words-br-consumed_words)*FLAC__BITS_PER_WORD + br-bytes*8
- br-consumed_bits;
}
Can you please try that and line me know if it works in MSVC? I know it
works for GCC and Clang as its required for C99.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fwd: flac 1.3.0pre1 prelease
* change instances of uint32_t in bitwriter.c to FLAC__uint32 Can we include inttypes.h 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 fix and move the function definitions to the header file and redo the patch. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
