[vorbis-dev] Re: Macintosh support (again)

[Joe Soroka]

>> 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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.