Someone mentioned that the problem I had compiling with the binary devel
distribution for Mac was that the .r file was supposed to be multiple
lines while the MPW was complaining that line 1 was too long and locking
up. I examined both SDL.r and SIZE.r. SIZE.r is just fine. SDL.r looks
like I opened a unix text file on Windows - all one line with a bunch of
squares mixed in with the text. This is the same in the source
distribution. This is from downloading both binary and source with
Mozilla and IE to make sure my download agent wasn’t causing the
problem. Anyone else have this problem? If so, this is a bug report…
I guess this could cause SDL or test apps not to compile correctly?
Cheers,
Mike
Randall Leeds wrote:> On Wednesday, January 2, 2002, at 01:11 AM, Mike Vanecek wrote:
Has OS-X implimented a more Unix like standardization of locations?
Like /usr/lib and /usr/include and so forth?
Indeed it has! In fact, there are a /usr/lib and /usr/include folders!
MacOS X installs as an option at install time the BSD Unix Subsystem
which is recommended for developers. It contains all the basic development
tools you find on your familiar linux. However, if you want you can also
use ProjectBuilder which is a very nice graphical development environment
that apple provides for free if you register with the Apple Developer
Connection
at their website. But if makefiles are what you like, you’re welcome to
use them.
In fact, it’s rather nice running MacOS X because when things don’t say
that they
work on MacOS, but that do do work on Linux, you can often download them
anyway
and compile them! YAY!
There’s even an XonX project that helps users set up XFree86 to run
along with OSX.
I did some tooling with it and got it to work, but slowly. I had GNOME
running, sort of
MacOS X opens a whole new world for mac users.
-Randall
I am amused by a workaround that the OGL headers implimented to
facilitate more crossplatform compatibility with Mac - they named
"GL.h" “GL/GL.h” with the forward slash so that "#include <GL/GL.h>"
would resolve correctly. Perhaps we can take a cue and do something
similar - copy “SDL.h” to “SDL/SDL.h” so that either/or would be
available. The CIncludes and Shared Libraries directories seem to be
the logical homes for the SDL resources - that way your make files are
simpler and don’t have to be edited by other Mac users with their own
folder placement - perhaps this can be recommended in documentation?
Cheers,
Mike
Randall Leeds wrote:
You’re not required to put the libraries anywhere. I used SDL
on classic for 1.0 and 1.1, not the most recent release.
You put the libraries and the headers wherever you want but
make sure to pop open the Makefile. The easiest thing to do
from my experience was to just use the Create Build Commands
(or something like that) in one of the menus and set up an application
like that. Also, make sure that you Get Info on the app or set it up
some other way so that you give your app plenty of RAM if you get it
to compile.
My directory structure was this when I did my building, maybe the SDL
libs have changed:
Project Dir
Libraries
SDL
SDLmain.o
Headers
All The SDL Headers
Then just pop open the Makefile, which if you stare at it long enough
you can figure out how it all works, and add a couple lines along
with all
the other libraries to link SDL and SDLmain.o.
Also, link the opengl libraries, I think they all start with OpenGL
and should be in the Shared Libraries folder with the MPW release,
either that or download the SDK from Apple.
I apologize if all of this is useless though, because my experience
with SDL on MacOS Classic is 1.0-1.1. By the time 1.2 came out I
had upgraded to X.
-Randall
On Tuesday, January 1, 2002, at 09:18 PM, Mike Vanecek wrote:
I’ll give that a go again - however, when compiling graywin from the
SDL_devel I got an error that the first line of SDL.r was too long
then the entire system just locked down. Ouch - twice. I have a
habit of compiling as much of everything I can on Linux and I was
following that habit after the binary devel locked up the system. I
figured either I got a corrupt SDL.r file, or that I goofed up the
installation - so I went with the good ol’ "compile it myself"
routine and hoped I could fill in the holes in the README.MacOS. Not.
You put the GL headers in the CIncludes, right? And the libraries in
the Shared Libraries folder? Did you also do the same with SDL? All
includes in the CIncludes and the libs in the Shared Libraries
folder? It’d be nice if there was a map or some documentation for
this…At least with Unix the directories for the stuff is clearcut
and easy and there’s more documentation than you can shake a stick
at. If I can figure all this out, perhaps I can put out a
Howto…unless there’s already one?
Thanks,
Mike
Randall Leeds wrote:
It’s certainly possible to use SDL on Classic MacOS.
For a long time I was programming SDL with MacOS 8.6.
However, I did not compile the library myself. I just downloaded
the compiled package from the SDL site.
You are right to use MPW though - my problem for a long time was
that CodeWarrior wasn’t cooperating.
You may want to try downloading the pre-built SDL if you don’t need
to make any modifications and it SHOULD work. Also, you might try
upgrading OS 9, or at least 8.6 if you still can’t get it working,
because
it worked for me on 8.6.
-Randall
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
http://dotfile.net/ - Dedicated to Open Source Software
Ack - all the .r files in the source distribution are like this… Only
SDL.r in the binary distribution is like that. Weird.
Mike
Michael Vanecek wrote:> Someone mentioned that the problem I had compiling with the binary devel
distribution for Mac was that the .r file was supposed to be multiple
lines while the MPW was complaining that line 1 was too long and locking
up. I examined both SDL.r and SIZE.r. SIZE.r is just fine. SDL.r looks
like I opened a unix text file on Windows - all one line with a bunch of
squares mixed in with the text. This is the same in the source
distribution. This is from downloading both binary and source with
Mozilla and IE to make sure my download agent wasn’t causing the
problem. Anyone else have this problem? If so, this is a bug report…
I guess this could cause SDL or test apps not to compile correctly?
Cheers,
Mike
Randall Leeds wrote:
On Wednesday, January 2, 2002, at 01:11 AM, Mike Vanecek wrote:
Has OS-X implimented a more Unix like standardization of locations?
Like /usr/lib and /usr/include and so forth?
Indeed it has! In fact, there are a /usr/lib and /usr/include folders!
MacOS X installs as an option at install time the BSD Unix Subsystem
which is recommended for developers. It contains all the basic
development
tools you find on your familiar linux. However, if you want you can also
use ProjectBuilder which is a very nice graphical development environment
that apple provides for free if you register with the Apple Developer
Connection
at their website. But if makefiles are what you like, you’re welcome
to use them.
In fact, it’s rather nice running MacOS X because when things don’t
say that they
work on MacOS, but that do do work on Linux, you can often download
them anyway
and compile them! YAY!
There’s even an XonX project that helps users set up XFree86 to run
along with OSX.
I did some tooling with it and got it to work, but slowly. I had
GNOME running, sort of
MacOS X opens a whole new world for mac users.
-Randall
I am amused by a workaround that the OGL headers implimented to
facilitate more crossplatform compatibility with Mac - they named
"GL.h" “GL/GL.h” with the forward slash so that "#include <GL/GL.h>"
would resolve correctly. Perhaps we can take a cue and do something
similar - copy “SDL.h” to “SDL/SDL.h” so that either/or would be
available. The CIncludes and Shared Libraries directories seem to be
the logical homes for the SDL resources - that way your make files
are simpler and don’t have to be edited by other Mac users with their
own folder placement - perhaps this can be recommended in documentation?
Cheers,
Mike
Randall Leeds wrote:
You’re not required to put the libraries anywhere. I used SDL
on classic for 1.0 and 1.1, not the most recent release.
You put the libraries and the headers wherever you want but
make sure to pop open the Makefile. The easiest thing to do
from my experience was to just use the Create Build Commands
(or something like that) in one of the menus and set up an application
like that. Also, make sure that you Get Info on the app or set it up
some other way so that you give your app plenty of RAM if you get it
to compile.
My directory structure was this when I did my building, maybe the SDL
libs have changed:
Project Dir
Libraries
SDL
SDLmain.o
Headers
All The SDL Headers
Then just pop open the Makefile, which if you stare at it long enough
you can figure out how it all works, and add a couple lines along
with all
the other libraries to link SDL and SDLmain.o.
Also, link the opengl libraries, I think they all start with OpenGL
and should be in the Shared Libraries folder with the MPW release,
either that or download the SDK from Apple.
I apologize if all of this is useless though, because my experience
with SDL on MacOS Classic is 1.0-1.1. By the time 1.2 came out I
had upgraded to X.
-Randall
On Tuesday, January 1, 2002, at 09:18 PM, Mike Vanecek wrote:
I’ll give that a go again - however, when compiling graywin from
the SDL_devel I got an error that the first line of SDL.r was too
long then the entire system just locked down. Ouch - twice. I have
a habit of compiling as much of everything I can on Linux and I was
following that habit after the binary devel locked up the system. I
figured either I got a corrupt SDL.r file, or that I goofed up the
installation - so I went with the good ol’ "compile it myself"
routine and hoped I could fill in the holes in the README.MacOS. Not.
You put the GL headers in the CIncludes, right? And the libraries
in the Shared Libraries folder? Did you also do the same with SDL?
All includes in the CIncludes and the libs in the Shared Libraries
folder? It’d be nice if there was a map or some documentation for
this…At least with Unix the directories for the stuff is clearcut
and easy and there’s more documentation than you can shake a stick
at. If I can figure all this out, perhaps I can put out a
Howto…unless there’s already one?
Thanks,
Mike
Randall Leeds wrote:
It’s certainly possible to use SDL on Classic MacOS.
For a long time I was programming SDL with MacOS 8.6.
However, I did not compile the library myself. I just downloaded
the compiled package from the SDL site.
You are right to use MPW though - my problem for a long time was
that CodeWarrior wasn’t cooperating.
You may want to try downloading the pre-built SDL if you don’t need
to make any modifications and it SHOULD work. Also, you might try
upgrading OS 9, or at least 8.6 if you still can’t get it working,
because
it worked for me on 8.6.
-Randall
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
http://dotfile.net/ - Dedicated to Open Source Software
Ack - all the .r files in the source distribution are like this… Only
SDL.r in the binary distribution is like that. Weird.
Thanks for the heads up, apparently the version of MPW I use doesn’t mind
this. I’ll correct it for future releases.
Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment