In order to compile the latest Vorbis library on the Macintosh, the change appended to this message needs to be made to os_types.h.in. Then, anyone who wants to actually build it must first copy os_types.h.in to os_types.h by hand, since MacOS does not include a command line and thus cannot run configure. It really bugs me that the whole "platforms which don't support configure scripts require multiple undocumented stages to build" issue hasn't been addressed yet. It's so simple to address, too -- just as simple as putting instructions for how to do the two-stage build into the documentation! Here's what needs to be done: 1. Rename os_types.h.in to os_types.h. 2. Move the one minor portion that's munged by configure into a new file, config_types.h.in. 3. Put '#include "config_types.h"' in place of the configure-munged stuff in os_types.h. 4. Then do whatever needs to be done (if anything) to make configure munge config_types.h.in instead of os_types.h.in. This will ensure that Windows and Macintosh developers can build the Vorbis libraries without making their own os_types.h, and without having to figure out that they need to. (They probably *won't* realize that they need to do this and instead just figure "Oh well, Mac/Windows support is broken just like it is with the rest of the Unix-oriented packages in the Universe. And besides that, it's still beta. I guess I won't bother with Vorbis.") -- Chris Hanson -- Mac developer -- Mac developer who has been evangelizing Vorbis to other Mac developers Here's the stuff to add to os_types.h.in (or os_types.h when my advice above is followed): Index: vorbis/include/vorbis/os_types.h.in ==================================================================RCS file: /usr/local/cvsroot/vorbis/include/vorbis/os_types.h.in,v retrieving revision 1.3 diff -u -2 -r1.3 os_types.h.in --- vorbis/include/vorbis/os_types.h.in 2000/08/30 07:09:46 1.3 +++ vorbis/include/vorbis/os_types.h.in 2000/10/05 20:35:38 @@ -37,4 +37,14 @@ typedef _G_int16_t ogg_int16_t; #endif + +#elif defined(macintosh) + +#include <sys/types.h> + +typedef SInt16 ogg_int16_t; +typedef SInt32 ogg_int32_t; +typedef UInt32 ogg_uint32_t; +typedef SInt64 ogg_int64_t; + #else --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> It really bugs me that the whole "platforms which don't support > configure scripts require multiple undocumented stages to build" > issue hasn't been addressed yet. It's so simple to address, too.It *is* a little annoying... But it probably just means the project needs mac and win32 leaders to make sure those things go smoothly. Lack of a win32 dll dsp/makefile is a good example. What good is LGPL if commercial companies can't make use of it? From a win32 stand point at least, libvorbis might as well be GPL. Not that I'm griping... These are minor issues and I'm very grateful just that this codec exists and works. I think an even easier fix for the problem is this: 1. make up a default os_types.h with the correct settings for win32 and macintosh (and beos I guess) 2. basically, add #if !defined(MAC) && !defined(WIN32) && !defined(whateverelse) #error "run ./configure before building on *nix platforms" #endif 3. check it in. Also, line 60 in lib/os.h is causing minor annoyances in win32 #include "../include/vorbis/os_types.h" I have a hunch it should probably be just "vorbis/os_types.h" like the rest of the #includes throughout the source. I'm sure there was a good reason for it, but I don't see it right now. Joe Soroka Senior Software Engineer Inphinity Interactive where the games begin... PS. here's my suggestion as a diff. (not tested thoroughly) note as well, that this is a *new* file and doesn't modify os_types.h.in, which should probably be cleaned up too since it wouldn't need to mention win32/mac/beos/cygwin targets anymore. Probably should add this os_types.h to a .cvsignore file too, so checkouts/updates grab the file but noone will accidentally commit their ./configure'd version. [someone@somewhere vorbis]$ diff os_types.h os_types.h.in 16,17c16,17 < function: default os_types.h for platforms without sh. < last mod: $Id: $ ---> function: #ifdef jail to whip a few platforms into the UNIX ideal. > last mod: $Id: os_types.h.in,v 1.3 2000/08/30 07:09:46 xiphmont Exp $38a39> #else40,48c41 < #elif defined(macintosh) < < #include <sys/types.h> < typedef SInt16 ogg_int16_t; < typedef SInt32 ogg_int32_t; < typedef UInt32 ogg_uint32_t; < typedef SInt64 ogg_int64_t; < < #elif defined(__BEOS__) ---> #ifdef __BEOS__51,54c44 < < #else // not win32, not mac and not beos < < #error "run ./configure before building on *nix platforms" ---> #endif--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
>It really bugs me that the whole "platforms which don't support >configure scripts require multiple undocumented stages to build" >issue hasn't been addressed yet. It's so simple to address, too -- >just as simple as putting instructions for how to do the two-stage >build into the documentation! Here's what needs to be done:True, the documentation in the tree wasn't updated when this change was made - but it was explained, in detail, on this list, within a day of the changes being made. Since you obviously read the list (or at least post to it, and presumably receive the list), it's not unreasonable to expect that you'd at least skim over it for relevent info like this. I agree that your proposal makes sense - but then, I don't like auto* in the first place (despite being a unix programmer first and foremost). Since I'm biased on the issue, I won't make the change myself. If you want vorbis to be more accessible to non-unix programmers (which is certainly an admirable goal), why not contribute makefiles/project files/whatever for your compiler, and keep them reasonably up to date? In fact, the copying os_types.h.in to os_types.h thing could then be trivially solved by making the makefiles (or equivalent) do this - something that every system I've used has been capable of, even if it's not always neat. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
>> I think an even easier fix for the problem is this: >> >> 1. make up a default os_types.h with the correct settings for win32 >> ... >> 3. check it in. > > Unfortunately, cvs doesn't support this. Since autoconf re-writes > os_types.h as part of the build process, the next time a developer did a > commit, the agnostic version would get 'patched'.Well, I don't know if you caught the PS at the end of my post, or you just knew in advance that the .cvsignore trick wouldn't work. At least it doesn't work with wincvs. Basically cvs does support what I described, it's just the cvs client's responsibilty to honour .cvsignore and I didn't try it out before offering it as a suggestion. Too bad; it would have been pretty simple and effective. I'll explain what I meant just so everyone can be as disappointed as me. 1. do up the default os_types.h just as you want it. 2. check it in. 3. create a .cvsignore file in the same directory, add os_types.h to it and check that in. 4. Now when someone does an update, they'll get both. 5. when someone tries to commit their autoconf'd os_types.h in over the default one, their cvs client should check cvsignore first and know to ignore the new version. I didn't bother checking if the command line client does this... wincvs certainly doesn't.> That's much worse than having generated code like configure in cvs, > which we do do. I don't think it's reasonable policy to require all > developers to replace the default before doing a commit.Yeah, no, of course not. I don't want you to think I was suggesting that.> The suggestion of having someone looking after the other platforms, > maintaining build documentation and project files is a better one, I > think.Well, I'm working on cleaning all that stuff up (win32) for my own project... I'd be happy to submit it. (This was all actually just a ploy to get cvs commit access)> Of course for actual code releases (like the beta source tarballs) > doing what you describe makes perfect sense. Maybe the thing to do is to > have os_types.[win32|mac|default] in cvs and use dist_hook to copy over > the default when the tarballs are made.Ah I see... yeah. Still no good for people on cvs or grabbing the cvs_nightly tgzs. No big deal, I guess. But os_types.h is only included in one file right? okay, two: os.h and codec.h but codec.h could be including "os.h" just as easily. So here are two different suggestions: 1. change os.h and have everyone include os.h instead of os_types.h (currently it appears that codec.h is the only other file including os_types.h) diff -r1.9 os.h 24a25,32> #define _OS_TYPES_BEING_INCLUDED_FROM_OS_H TRUE > #if defined(WIN32) || defined(macintosh) || defined (BEOS) > #include "vorbis/os_types.h.in" > #else > #include "vorbis/os_types.h" > #endif > #undef _OS_TYPES_BEING_INCLUDED_FROM_OS_H >59,60d66 < < #include "../include/vorbis/os_types.h" .. and modify os.h suchly: diff -r1.3 os_types.h.in 20a21,24> #if !defined(_OS_TYPES_BEING_INCLUDED_FROM_OS_H) > #error "please include 'os.h' not 'os_types.h'." > #endif.. and codec.h as well: diff -r1.29 codec.h 29c29 < #include "os_types.h" ---> #include "os.h"The problem then is that codec.h is expecting to find os.h in its current directory, not ../../lib where it exists. Of course, then you could move os.h from lib to include/vorbis (why is it in lib anyways? I'm sure there's a good reason but...) Finally, that would require changing everything else to include "vorbis/os.h" instead of "os.h" as they do now. - Okay so that way kind of sucks in terms of risk/benefit, so here's a simpler way that wouldn't break anything.. 2. "rename" os_types.h.in to somethingelse.h.in and have the configure scripts produce somethingelse.h ... then check in a os_types.h that looks like this: #ifndef _OS_TYPES_H #define _OS_TYPES_H #if defined(WIN32) || defined(macintosh) || defined(BEOS) #include "somethingelse.h.in" #else #include "somethingelse.h" #endif #endif low footprint - low impact. only issue is choosing a good name. whaddya think? --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> In order to compile the latest Vorbis library on the Macintosh, the > change appended to this message needs to be made to os_types.h.in. > Then, anyone who wants to actually build it must first copy > os_types.h.in to os_types.h by hand, since MacOS does not include a > command line and thus cannot run configure.Ok, let's start using the correct names for things, as it took me a while to figure out what the hell this was all about. os_types.h isn't in vorbis. It's in ogg.> It really bugs me that the whole "platforms which don't support > configure scripts require multiple undocumented stages to build" > issue hasn't been addressed yet.It was addressed. These are new changes, and we're going around cleaning up the stuff we missed. Since I don't personally have a mac to build this stuff on, I'm goin to wait until you guys point stuff out until I fix something :) Same goes for BeOS. I do however have win32 around, and I will get around to making those build probelsm go away with correct project files etc.> 1. Rename os_types.h.in to os_types.h. > > 2. Move the one minor portion that's munged by configure into a new > file, config_types.h.in. > > 3. Put '#include "config_types.h"' in place of the configure-munged > stuff in os_types.h. > > 4. Then do whatever needs to be done (if anything) to make configure > munge config_types.h.in instead of os_types.h.in.This was fairly elegant, and has been done and committed. Thanks for the patch at the bottom, I included it in a slightly different place, but it should have the same effect. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.