Vorbis dev - Jan 2005 - 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

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

----- 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 support
The 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.