|
Source distribution |
ngiacomelli
Member #5,114
October 2004
|
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?
|
kazzmir
Member #1,786
December 2001
|
1. make the source available |
ngiacomelli
Member #5,114
October 2004
|
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?
|
Joel Pettersson
Member #4,187
January 2004
|
Archon
Member #4,195
January 2004
|
Quote: how do I distribute my source code for Linux and Mac users? 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. |
kazzmir
Member #1,786
December 2001
|
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 ). |
ngiacomelli
Member #5,114
October 2004
|
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?
|
Archon
Member #4,195
January 2004
|
Quote: 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:
|
Audric
Member #907
January 2001
|
|
James Stanley
Member #7,275
May 2006
|
Archon, since when did you need a '\ '? |
Indeterminatus
Member #737
November 2000
|
Quote: Archon, since when did you need a '\ '? Alternatively, avoid spaces in filenames. _______________________________ |
Evert
Member #794
November 2000
|
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 \ Quote: Archon, since when did you need a '\ '? 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)? Quote: End-of-line separator is \n\r in the DOS family, \n in *nix, \r on Mac. MacOS X is UNIX based, and the line separator is \n. |
Andrei Ellman
Member #3,434
April 2003
|
-- |
TeamTerradactyl
Member #7,733
September 2006
|
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
|
Ultio
Member #1,336
April 2001
|
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. --- |
|