Hi there,
I’ve been working for many small scale projects, but now I’m
starting the development of a larger project. A project that will
probably require CVS since we’ll be a couple programmers working on
the different modules of the software. We will be developing the
software for all popular platforms like Linux and windows (done by
myself) and MacOS 7,8,9 (done by one of my collegues) and MacOS X
(probably will be done by myself eventually).
I would need to know if there is a standard practice for making a
platform-dependent coding. Using #ifdef MAC_OS_CLASSIC or something
like that… is there anything builtin that I can use to compile for
the right platform?
I tried looking on google for ./configure and got a headache. Can
you guys refer me to a page that explains how to use it?
S> Hi there,
S> I’ve been working for many small scale projects, but now I’m
S> starting the development of a larger project. A project that will
S> probably require CVS since we’ll be a couple programmers working on
S> the different modules of the software. We will be developing the
S> software for all popular platforms like Linux and windows (done by
S> myself) and MacOS 7,8,9 (done by one of my collegues) and MacOS X
S> (probably will be done by myself eventually).
S> I would need to know if there is a standard practice for making a
S> platform-dependent coding. Using #ifdef MAC_OS_CLASSIC or something
S> like that… is there anything builtin that I can use to compile for
S> the right platform?
S> I tried looking on google for ./configure and got a headache. Can
S> you guys refer me to a page that explains how to use it?
If you can steer clear of autohell, do so. Personally, I use a Visual
Studio project for my Windows builds, and use a hand-crafted Makefile
for Linux and OS X, detecting which is which by using a combination of
compiler defines, and the output of gcc -dumpmachine. I really don’t
know about Classic, personally we stopped supporting Classic when OS X
10.2 came out.–
Best regards,
Peter mailto:@Peter_Mulholland
When I first looked at autotools I had the same feeling as you, but
I’ve actually come to the point where I like it quite much.
Read and understand the “autobook” which covers all the stuff you’ll
ever need to know about autoconf and automake:
If you can steer clear of autohell, do so. Personally, I use a Visual
Studio project for my Windows builds, and use a hand-crafted Makefile
for Linux and OS X, detecting which is which by using a combination of
compiler defines, and the output of gcc -dumpmachine. I really don’t
know about Classic, personally we stopped supporting Classic when OS X
10.2 came out.
That sounds interesting, could you give a very simple example on how
to use the compiler defines and gcc -dumpmachine ? I have a good
idea, but it’s just the compiler defines I don’t get…
There are packages like SDL around whose sole purpose is to
provide an abstraction layer which hides portability issues.
SDL cant hide everything
Yup, for example, in my project, I will be forced to support MacOS
classic. I think the lowest we have to support is MacOS 7.6. One of
my friend is the MacOS classic expert, he’ll probably bypass SDL
completely.
Many things are not supported by SDL and its libraries (net, image,
etc…) on MacOS 7.6, and this is where I’ll need to have pre-compiler
code to separate what goes on Mac7.6 and what goes everywhere else.
I just never done this, I was wondering about your suggestions, I will
check autoconf and the others, I will make my own mind on it. If you
have any other suggestions, please, feel free to send them here or to
me by email.
Yup, for example, in my project, I will be forced to support MacOS
classic. I think the lowest we have to support is MacOS 7.6. One of
my friend is the MacOS classic expert, he’ll probably bypass SDL
completely.
Darn. :^)
Many things are not supported by SDL and its libraries (net, image,
etc…) on MacOS 7.6, and this is where I’ll need to have pre-compiler
code to separate what goes on Mac7.6 and what goes everywhere else.
I’d just love to have Tux Paint working on OS9.[*] I’d be willing to drop
some functionality. :^)
[*] Since there are still many schools with rooms full of old Macs.On Sun, Feb 26, 2006 at 01:50:03AM -0500, Simon wrote:
There are packages like SDL around whose sole purpose is to
provide an abstraction layer which hides portability issues.
SDL is great and all for portability but let’s not confuse things. An
abstraction layer like SDL does nothing in regards to providing a
portable build procedure (save for sdl-config, but that’s only a small
part of the whole picture).
IMHO, these packages are a much better idea than auto* tools.
I agree that the autotools suck (relying on an archaic language no one
cares about, deficient Windows support, vastly overcomplicated, hard
to maintain, hard to integrate with IDEs, unpractical for non-posixish
native applications, the list goes on and on…), but they have their
purpose.On 2/26/06, skaller wrote:
There are packages like SDL around whose sole purpose is to
provide an abstraction layer which hides portability issues.
SDL cant hide everything
Yup, for example, in my project, I will be forced to support MacOS
classic.
I am curious why you want to support it … (your choice
of course)
I just never done this,
I have ;(
I was wondering about your suggestions, I will
check autoconf and the others, I will make my own mind on it. If you
have any other suggestions, please, feel free to send them here or to
me by email.
The tool we use is called “Python”. You may prefer Perl.On Sun, 2006-02-26 at 01:50 -0500, Simon wrote:
I agree that the autotools suck (relying on an archaic language no one
cares about, deficient Windows support, vastly overcomplicated, hard
to maintain, hard to integrate with IDEs, unpractical for non-posixish
native applications, the list goes on and on…), but they have their
purpose.
Indeed: to bootstrap the process of building build tools
such as gcc, glibc, make, binutils, and other such things
which are intrinsic to a Unix development environment.
But they shouldn’t be used by application programmers. IMHO.On Sun, 2006-02-26 at 02:09 -0500, Simon Roby wrote:
Yup, for example, in my project, I will be forced to support MacOS
classic. I think the lowest we have to support is MacOS 7.6. One of
my friend is the MacOS classic expert, he’ll probably bypass SDL
completely.
Actually, I just got SDL CVS updated to work on MacOS Classic. I’d love it
if he took a look at it.
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
I agree that the autotools suck (relying on an archaic language no one
cares about, deficient Windows support, vastly overcomplicated, hard
to maintain, hard to integrate with IDEs, unpractical for non-posixish
native applications, the list goes on and on…), but they have their
purpose.
I agree to you (and all those who think like you about the autotools),
but is there any alternative?
If you can provide reference to alternatives that can help build on
Linux, Windows and MacOS classic and X, that would be great.
I am curious why you want to support it … (your choice
of course)
Well, I’ve always had a Mac at my parents house, now I’m on a PC with
linux, my friends have Windows. So I’d say “Compatibility” has a
great place in my heart. Compatibility provides great challenges and
and a good compatible software always yields admiration. One other
very good reason is that the guy who will support the MacOS 7-8-9 has
an old PPC and wants to be able to use it.
The tool we use is called “Python”. You may prefer Perl.
I know both, I never really practiced any of these, how would you use
them? Can you show me an example (for how it can help compile…)?
Actually, I just got SDL CVS updated to work on MacOS Classic. I’d love it
if he took a look at it.
Mr. Lantinga, it will be a pleasure to add any corrections to the
MacOS part of SDL. Do you know what functions have problems on MacOS
(what’s not quite supported, etc…)?
Actually, I just got SDL CVS updated to work on MacOS Classic. I’d love it
if he took a look at it.
Mr. Lantinga, it will be a pleasure to add any corrections to the
MacOS part of SDL. Do you know what functions have problems on MacOS
(what’s not quite supported, etc…)?
Here’s the list from the BUGS file:
MacOS:
Palette handling isn’t implemented in windowed mode yet.
Audio hasn't been extensively tested, in particular the locking
isn't implemented and mixer routines may not call malloc() or free()
because they are called at interrupt time.
SDL_WM_GrabInput() is not implemented.
Does anyone know how to do this? SDL_WM_GrabInput() is designed
to prevent the user from switching input and mouse focus away from
the SDL application.
Continuous relative mouse motion is not implemented.
SDL_AddTimer() and SDL_RemoveTimer() haven't been implemented yet.
Not all of the keys are properly recognized on the keyboard.
I’m sure you’ll have a better feel for what’s missing by just trying it out.
Ok, I’ve forwarded this post to my friend working on the Mac version.
He’s very busy studying at the university and working at the same
time, but I’ll keep you updated of any development.
If you can provide reference to alternatives that can help build on
Linux, Windows and MacOS classic and X, that would be great.
Hi,
For my SDL lib I’m using scons. This is a python based build package
that I use
for building at least on windows and linux. It can detect installations of gcc
and visual studio without changing any of the scripts. Actually for all
platforms it tries to find the correct compiler.
That means it works out of the box for windows and linux. Unfortunatly I don’t
own a mac or know someone who has one. So I can’t test it for this platform.
According to the site www.scons.org it supports Linux, other POSIX systems
(including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X,
and OS/2.
Syntax is really simple, even if you don’t know python.
