Andre Pang
2005-Jan-05 10:00 UTC
[Vorbis-dev] Status of Windows builds for libvorbis/libogg
Hi all, I've just done a quick check of the libvorbis Visual C++ 6.0 project on Windows, and am happy to say that both libvorbis and libogg build fine. (Theora isn't quite so lucky -- see the theora-dev mailing list for details on that.) There are two suggestions I can make, though: 1. To build properly, the directories must be checked out with certain names, and in paths relative to each other. Specifically, both libogg and libvorbis must be checked out in the same directory, and libogg must be checked out to directory named "ogg". (libvorbis can be checked out to whatever directory name you like, although it's strongly recommended to call it "vorbis", since that'll make it work with properly with the theora Windows builds.) Because of the particular directory structure requirements, I'd suggest having a Subversion checkout path which uses svn:externals to pull down all the appropriate required libraries, so that a Windows developer can check out a single URL and have all the files sitting on their local machine in good order. It looks like http://svn.xiph.org/trunk/win32sdk did this for CVS, but it needs to be upgraded to work with Subversion now. 2. Along with the Visual C++ 6.0 projects (the .dsp/.dsw files), it would be good Visual Studio .NET 2003 solution and project files (.vcproj/.sln), so that Windows developers who are using the more recent versions of Visual Studio can compile stuff too. Zen (illiminable) has already done this in the oggdsf/ tree. I think the best approach would be to coordinate with him and the respective codec maintainers on getting the VS.NET 2003 files into the original ogg/vorbis/theora/speex/(flac?) trees, not only so that we gain support for VS.NET 2003, but also so that the oggdsf tree can just use svn:externals to remain in sync with the trunk, rather than re-importing the source trees of each of the codecs into the oggdsf tree. Unless there are any objections, I'm happy to go ahead and make these changes over the coming week or two. -- : Andr? Pang (x4180) : Software Engineer, Networked Media : CeNTIE
Ralph Giles
2005-Jan-05 11:04 UTC
[Vorbis-dev] Status of Windows builds for libvorbis/libogg
On Thu, Jan 06, 2005 at 02:29:37AM +1100, Andre Pang wrote:> [good ideas snipped] > Unless there are any objections, I'm happy to go ahead and make these > changes over the coming week or two.Sounds lovely, please do. Note that we've been waiting on exactly this cleanup for doing a new win32 sdk release, essentially a .zip with dlls build and the source arranged as you've suggested. Would you be up for doing such a release once stuff is the way you like it in svn? Thanks for the help, -r
illiminable
2005-Jan-05 18:02 UTC
[Vorbis-dev] Status of Windows builds for libvorbis/libogg
----- Original Message ----- From: "Andre Pang" <Andre.Pang@csiro.au> To: <vorbis-dev@xiph.org> Sent: Wednesday, January 05, 2005 11:29 PM Subject: [Vorbis-dev] Status of Windows builds for libvorbis/libogg> 2. Along with the Visual C++ 6.0 projects (the .dsp/.dsw files), it > would be good Visual Studio .NET 2003 solution and project files > (.vcproj/.sln), so that Windows developers who are using the more recent > versions of Visual Studio can compile stuff too. Zen (illiminable) has > already done this in the oggdsf/ tree. I think the best approach would be > to coordinate with him and the respective codec maintainers on getting the > VS.NET 2003 files into the original ogg/vorbis/theora/speex/(flac?) trees, > not only so that we gain supportThe reason i've never worried about getting my current project files into the tree is they reference each other in a way specific to my tree. ie the include paths point to other places in my tree, that wouldn't exist unless they have my tree. Also because of the size of my project... i build against MT DLL's (which brings with it the penalty of distributing 700k of runtimes) but when it's spread over 70 libraries as it is in my case, it's actually better than the static alternative. But for someone just wanting to build the xiph tools, they would be better built against MT Static runtimes. I actually prefer that my project files aren't in the main tree, since it lets me randomly make changes to configurations to optimise for my project without having to worry about how that affects anyone else who wants to use them. Though certainly copy my project files as a examples, and perhaps check those modified versions in. Zen.