This may sound like a silly question, but how do I distribute my source code for Linux and Mac users? The most common problem I see when people distribute a game with source included is Linux/Mac people having to comb through it to change #include's to fix path issues.

Are there other things I should avoid, and what should I include with the code? I've never made a makefile, will I have to do this?

1. make the source available
2. wait for a kindly user to fix the path issues and probably write a makefile
3. profit!

kazzmir, as much as I enjoy numeric lists, I actually posted here so that I could take steps towards avoiding having a 'kindly user' fix my code.

I keep all of my source and header files in a single directory, so path issues shouldn't be a problem. Are there any good tutorials for creating my own makefile?

You could begin with the manual.

With Linux, you could run a LiveCD and install Allegro (temporarily) for it and fix your code until it compiles and runs.

I don't know about the Mac though... If their MacOSX was free I would test it.

I got the hint from your post that you weren't actually going to try compiling your project for Linux or Mac yourself and just pray to the gods it would work somehow. If thats the case then I guarantee it will fail. If it is not the case then your line of questioning doesn't make too much sense because if you can't compile it yourself then how is someone else going to.

I have Linux and OSX, so I wouldn't mind fixing it for you( as long as its not a beast of a project ).

kazzmir: sorry about the grumpy reply, I must not have been in a particularly festive mood!

Here's an example snippet from the file render.c:

#include <allegro.h>
#include <math.h>
#include <stdio.h>
#include "canvas.h"
#include "application.h"
#include "player.h"
#include "object.h"
#include "monster.h"
#include "shop.h"
#include "map.h"

As I stated, all of my files are in the same folder. What I was really hoping to do was create a makefile and then have someone test it, rather than fix my code for me. Are there any other code-related pitfalls I should watch out for?

I'm not sure what you know, but here's what I can think of:

• File paths are case sensitive (for linux at least)

• Use / instead of \ (for file paths again)

• Use "\ " (slash + space) when there is a space

• Can't use winalleg.h without the #ifdef WINDOWS or whatever.

• If you change compilers, there may be changes in the syntax (mainly with MSVC vs GCC)

• Maybe there could be features not implemented in the MAC OSX version of Allegro

• End-of-line separator is \n\r in the DOS family, \n in *nix, \r on Mac. If you need to read/write TEXT files with the libc functions, be sure to specify "t" in the fopen() mode, and then the functions will interpret your '\n' accordingly.

Archon, since when did you need a '\ '?

Alternatively, avoid spaces in filenames.

If you don't include platform-specific headers (ie, only standard C headers and allegro.h), there shouldn't be a problem with headers. Case sensitivity and / vs \
are the most common problems beside that, but they are easy to fix and avoid.

I've always needed it (when there's a space in the filename). How else do you tell that the space is part of the name and not a separation character (yes, they should be avoided)?

MacOS X is UNIX based, and the line separator is \n.

fix_filename_slashes()

Nial Giacomelli,

Since most of the regular C/C++ code you will write use the allegro functions (which wraps the appropriate Windows/*nix/Mac calls it needs to do its thing), I would say that most of your code should be easily ported to other platforms.

Besides the good ideas posted above, you may still have SOME functions that require OS-specific code. In that case, some people put those specific functions into separate files: dos.c, linux.c, mac.c, win.c, ...

Then, just like Allegro's "fix.bat" does, create the different makefiles you wish to use to compile the program. If you use "fix.bat mac", it may #include the "makefile.mac", while the "fix.bat mingw" would #include "makefile.win", etc. Those separate makefiles would specify that their respective "OS-specific" files needed to be added to the list of compiled sources when you're making your final program.

Then, if you don't know how to code specifically for the individual OS (like, I don't know how to code for Mac/Linux very well), someone else may be able to come along and provide the OS-specific things you need for your code, and you can almost entirely dismiss the need for #ifdef WINDOWS or #ifdef LINUX, etc.

-My 2 cents

Another pitfall that is OSX specific: Allegro apps do not run in fullscreen mode in a 16bit depth. If you're defaulting to 16bit for your project, you need some kind of catch that will find an alternate, or #ifdef block/define to default your Mac build to go 15 (or 32).

Stuff like this is a pain to know, but once you know it you should be all set. That aside, if you're worried about compilation issues: if it builds in Linux/Unix with a plain makefile, chances are it should build without a hitch under OSX.