quake3 MacOS hackery, continued...

[Tim Angus]

On Sun, 27 Nov 2005 20:25:16 -0500 Ryan wrote:
> It's not source control, it's a revision control system. We have the
> web site in here, too, for example.

It would be nice if that were separate to be honest. It really screws
with the revision numbers.

> Semantics aside, you need these libraries when building from source as
> much as you need them in an installer or at runtime. As I said, it
> makes sense for Linux distros to manage these dependencies (or Linux
> users to hunt them down, although frankly I don't like the assumption
> that they should do more work, but binary incompatibility demands
> it)...as such I haven't added them to svn for Linux. But on the Mac
> and Windows, you shouldn't be telling people "oh, go find this,
> possibly build it, also do this workaround to SDL's build system to
> make sure it builds correctly on the Mac, and copy it to the following
> place, which may be just about anywhere on Windows"

This is really reiterating what I said before... I'm not sure there is
really any point in making the Windows and Mac builds "easy". I fully
expect (at least my experience indicates) that Windows and Mac users
couldn't give a damn about how easy the project is to compile. Your
average user is going to want a nice installer package that just works.
Windows and Mac users that are intrepid enough to actually want to
compile the thing are by virtue going to have at least a minor
understanding of building software. This is not the case on Linux (yet),
where knowing how to compile something from source is regrettably still
relatively important. What I'm getting at is that ease of compilation
doesn't seem to me to be particularly important on these platforms. Case
in point: on the IRC channel there are regularly Linux people having
trouble building ioq3. I am aware of a grand total of one user building
the MinGW build, and he has yet to ask any questions regarding the build
process (before the recent breakage anyway).

> OpenAL and SDL are not "system headers" ... I'm not advocating adding
> stdio.h to subversion here. These are third-party external
> dependencies that we rely upon.

Should we include OpenGL and DirectX headers too?

> That being said, the OpenAL headers I included were from AL1.0...if
> this broke something, let's update them...

This is really my major gripe. By having the headers in SVN, it is now
up to us to ensure the headers are up to date and appropriate for the
platform we're using. I don't think this is something we should really
need to do.

The current AL headers definitely need to be upgraded.

> but it should also
> demonstrate why relying on the end-user to supply these is dangerous,

When a release is actually made, we don't NEED to rely on the end-user
since we'll give them nice binary packages that "just work".

> since there are probably users out there with the same headers, and
> they're either going to write a bug report which we would have to flag
> INVALID or they'll go "this project sucks" and not use it. Or both.

Pleasingly, I'm aware of very few bugs involving build problems. Most
people seem to attack the mailing list or the IRC channel, and they
usually get a prompt response.

If we do stick with having the headers in SVN, at the very least it
needs to be a build option to use system headers instead.