Hi everyone.
I wanted to port some of my applications on linux , and after some research i had a great success.
What i want to know , is :
1) How can i make a simple make file?(using the command line everytime is a pain in the a--)
For example , lets say that i have the following source files :
ResourceMan.cpp , Main.cpp (includes: sdl,opengl)
How can i setup the makefile?
2)Fmod works on linux? or should i go with openal?
3)The compiled application will work on every linux distro?
or i always have to release my source ?
Thanks.
Game development & linux
Started by WannaDev, Dec 25 2007 12:30 PM
6 replies to this topic
#1
Posted 25 December 2007 - 12:30 PM
#2
Posted 25 December 2007 - 01:27 PM
3) Yes, Linux uses the ELF binary format, so every distro will be able to run your app. The only thing you have to watch out for is whether or not those people will have the necessary shared objects (DLL files). If you compile your project with static libraries, you'll be fine.
2) I use OpenAL in Linux, so I can vouch for that. It has everything you need and a little more if you want.
1) Here's an example makefile from my template project:
This will produce a statically linked executable with all the libraries listed above, except libraries like OpenAL where I have to compile it as a Shared Object (DLL in Windows). Just to go through ti quickly:
Options
The Options field is just assigning commonly used terms to variables. It makes the makefile more manageable and easier to change settings such as what compiler you'll be using. There's no specific variable naming convention in use here (you could use "COMPILER" instead of "CC"), although it helps others to quickly use your makefile if you use the same naming conventions as everyone else.
AR - Short for "Archiver". This program basically merges together all your static .lib files. It's not necessary to use for shared libraries (if you plan on using .so objects).
CC - Command line name of the compiler you will be using. g++, gcc, etc...
CFLAGS - Compiler flags. You'll need to see the man page for g++ in order to get a list of them. The most common ones are "-g" which outputs debugging information for the GDB (runtime debugger) and "-Wall" (enable all warnings).
LFLAGS - Link flags. Same as CFLAGS except at the linking stage.
INCLUDES - The location of all your include folders. Separate each new directory with a space.
LIBS - Same as INCLUDES, but for library files.
OUT - Location of where to dump the binary files to.
Project Name
Every makefile by default has the project directive "all", meaning do everything. So this way all you have to do is go into the folder and type "make", and the "all" directive will be executed. If you used a different name here, say "mygame: template", then you would have to type in "make mygame" every time or get an error. Always make sure to have an "all" directive.
Application to Compile
APPSRCS - This list all the .cpp files to compile. You must separate all files by a space, and if you want to make it neater you can add a slash '\' and escape to the next line. In makefiles, whenever you escape to the next line, you MUST use a tab key to indent the text over. Make needs this to parse your file.
APPOBJS - Once g++ compiles your code into objects, it will need to link them into the final executable later. This is a simple macro that takes all the cpp files you defined in APPSRCS, and changes the extension from .cpp to .o.
APPLIBS - This defines all the libraries used in your application. Keep in mind, g++ will use the "LIBS" option defined above to search for these libraries. Each library begins with an -l. The following is the name of the library, so -lapp means look for the library libapp.lib. Yes, libapp. I didn't write that, but it's implied by the g++ compiler. If my library were called app.lib, then -lapp would give a link error since g++ would not be able to find libapp.lib. It's just a standard used by the C/C++ compiler.
template - This is the name of your project (listed in the all directive, they have to match!). This field just does a standard compile/link routine, using the options listed above.
Implicit Compile
Using the macro defined in APPOBJS, this will get make to use GCC to compile all cpp files into objects.
Clean
When you compile, you get a lot of object files that mess up your project. Use the clean directive (make clean) to delete all those files and keep a clean project.
2) I use OpenAL in Linux, so I can vouch for that. It has everything you need and a little more if you want.
1) Here's an example makefile from my template project:
##### Options #####
AR = ar
CC = g++
CFLAGS = -g -Wall
LFLAGS =
INCLUDES = -I../engine/inc -I./ -I./src
LIBS = -L../engine/lib
OUT = bin/
##### All #####
all: template
##### App ######
APPSRCS = scene/CSceneGeneric.cpp \
scene/menu/CSceneMenu.cpp
APPOBJS = $(APPSRCS:.cpp=.o)
APPLIBS = -lapp -lsound -lgui -lresource -lrenderer -lanimation -linput -levent -lmath -lcommon -lutility -lpthread -lGLU -lGL -lX11
template: $(APPOBJS)
$(CC) ${LFLAGS} $(APPOBJS) -o ${OUT}$@ $(LIBS) ${APPLIBS}
##### Implicit Compile #####
.cpp.o:
$(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@
##### Clean #####
clean:
rm -f $(APPOBJS)
This will produce a statically linked executable with all the libraries listed above, except libraries like OpenAL where I have to compile it as a Shared Object (DLL in Windows). Just to go through ti quickly:
Options
The Options field is just assigning commonly used terms to variables. It makes the makefile more manageable and easier to change settings such as what compiler you'll be using. There's no specific variable naming convention in use here (you could use "COMPILER" instead of "CC"), although it helps others to quickly use your makefile if you use the same naming conventions as everyone else.
AR - Short for "Archiver". This program basically merges together all your static .lib files. It's not necessary to use for shared libraries (if you plan on using .so objects).
CC - Command line name of the compiler you will be using. g++, gcc, etc...
CFLAGS - Compiler flags. You'll need to see the man page for g++ in order to get a list of them. The most common ones are "-g" which outputs debugging information for the GDB (runtime debugger) and "-Wall" (enable all warnings).
LFLAGS - Link flags. Same as CFLAGS except at the linking stage.
INCLUDES - The location of all your include folders. Separate each new directory with a space.
LIBS - Same as INCLUDES, but for library files.
OUT - Location of where to dump the binary files to.
Project Name
Every makefile by default has the project directive "all", meaning do everything. So this way all you have to do is go into the folder and type "make", and the "all" directive will be executed. If you used a different name here, say "mygame: template", then you would have to type in "make mygame" every time or get an error. Always make sure to have an "all" directive.
Application to Compile
APPSRCS - This list all the .cpp files to compile. You must separate all files by a space, and if you want to make it neater you can add a slash '\' and escape to the next line. In makefiles, whenever you escape to the next line, you MUST use a tab key to indent the text over. Make needs this to parse your file.
APPOBJS - Once g++ compiles your code into objects, it will need to link them into the final executable later. This is a simple macro that takes all the cpp files you defined in APPSRCS, and changes the extension from .cpp to .o.
APPLIBS - This defines all the libraries used in your application. Keep in mind, g++ will use the "LIBS" option defined above to search for these libraries. Each library begins with an -l. The following is the name of the library, so -lapp means look for the library libapp.lib. Yes, libapp. I didn't write that, but it's implied by the g++ compiler. If my library were called app.lib, then -lapp would give a link error since g++ would not be able to find libapp.lib. It's just a standard used by the C/C++ compiler.
template - This is the name of your project (listed in the all directive, they have to match!). This field just does a standard compile/link routine, using the options listed above.
Implicit Compile
Using the macro defined in APPOBJS, this will get make to use GCC to compile all cpp files into objects.
Clean
When you compile, you get a lot of object files that mess up your project. Use the clean directive (make clean) to delete all those files and keep a clean project.
http://www.nutty.ca - Being a nut has its advantages.
#3
Posted 25 December 2007 - 02:19 PM
Thanks for your time , i couldnt ask for a better answer!
I have to -study-(not just read) carefully your message , before i start.
I have to -study-(not just read) carefully your message , before i start.
#4
Posted 26 December 2007 - 12:16 PM
Heh , just compiled a test project and everything went fine...with one exception...-Wall flag was giving me a bunch of warnings,and i removed it (bad idea?).
Thanks again.
Thanks again.
#5
Posted 26 December 2007 - 02:12 PM
There is a linux game development article series at gamedev.net that could be useful for you. Here is a link to the first article: linux game development
WildChild
WildChild
#6
Posted 26 December 2007 - 11:33 PM
While it's not mandatory in most cases to fix warnings, it's generally encouraged. Not only does it help you become a better programmer, but it helps to keep your code cleaner and potentially run more efficiently. For myself, I make it a habit to have no warnings.
http://www.nutty.ca - Being a nut has its advantages.
#7
Posted 27 December 2007 - 01:18 AM
Specifically, what warnings were you getting?
g++ with -Wall gives warnings for certain things that really are harmless - for instance if you define a constant in a header file, you'll get a warning for every source that includes the header but doesn't ever use the constant. Also it gives warnings about #pragmas that I have in there for MSVC, even when they are wrapped by #ifdef _MSC_VER. Quite annoying really. However you can turn those specific warnings off (-Wno-unknown-pragmas and -Wno-unused IIRC), which should be your weapon of choice rather than simply turning off all warnings.
g++ with -Wall gives warnings for certain things that really are harmless - for instance if you define a constant in a header file, you'll get a warning for every source that includes the header but doesn't ever use the constant. Also it gives warnings about #pragmas that I have in there for MSVC, even when they are wrapped by #ifdef _MSC_VER. Quite annoying really. However you can turn those specific warnings off (-Wno-unknown-pragmas and -Wno-unused IIRC), which should be your weapon of choice rather than simply turning off all warnings.
reedbeta.com - developer blog, OpenGL demos, and other projects
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users












