rookie questions
Author
I got three questions.
1) I'm making a game engine and game editor in KDevelop. I have about 50 .h and .cpp files that I wrote for both programs. Many of those .h and .cpp files are exactly the same in both programs. Every time I'm working on one program and I alter one of those "shared" files I have to copy the new one into my other program directory as well. It would be smarter to have those shared files in separate directory and have the compiler find it there. How do I do that?
2.) How would I do the same thing from a command line with g++?
3.) I can only compile my programs with KDevelop. When I try compliling my program at a command line I do something like
g++ programs.cpp -o program -lSDL
but then it can't find SDL.h
How come KDevelop can find SDL.h but I can't find it from a command prompt?
Quote:Original post by icecubeflower
I got three questions.
1) I'm making a game engine and game editor in KDevelop. I have about 50 .h and .cpp files that I wrote for both programs. Many of those .h and .cpp files are exactly the same in both programs. Every time I'm working on one program and I alter one of those "shared" files I have to copy the new one into my other program directory as well. It would be smarter to have those shared files in separate directory and have the compiler find it there. How do I do that?
I've never used KDevelop, but I am sure you can create project dependencies since its an IDE. Put all of the shared .h and .cpp files into a seperate project. Then set that project as a build dependency for the game engine project and for the game editor project. Also have the game engine and the editor include the .h files directly from the folder in which the shared files are. The only problem you might run into, is that the IDE might not be able to find the .o (object files) for the shared code. To solve this you may have to add the directory of the shared code as an external dependency to your engine project and your editor project, or compile the shared code into a static libarary and have both projects link to it.
Quote:
2.) How would I do the same thing from a command line with g++?
I would create a makefile for the engine and for the editor. Both makefiles have instructions to compile the shared code. If it was already compiled previously than the object files will just be linked in to the specific program you are compiling (i.e. the engine or the editor)
Quote:
3.) I can only compile my programs with KDevelop. When I try compliling my program at a command line I do something like
g++ programs.cpp -o program -lSDL
but then it can't find SDL.h
How come KDevelop can find SDL.h but I can't find it from a command prompt?
That depends on how you are including SDL.h and where SDL.h is located. If SDL.h is located somewhere in "/usr/include/" and you are including it as <SDL.h> in your files than you should not be having problems. If its located somewhere else then you need to compile your code like this:
g++ programs.cpp -o program -I/folder/where/sdl/header/file/is -lSDL
-------------------------------------- ^ ----------------------------
(thats a capital i, not an l)
I have two bits of advice.
First, if you have surces shared between two programs, you should factor them into a library and share that library between programs. No copying, just simple compile-time dependencies. That's what libraries were invented for back when punched cards were in stylish vogue.
Second, and at least this used to be true and I think it still is, KDevelop is a gui interface around the de facto standard POSIX build system of using the "make" command-line tool to build programs. If you want to build your program from the command line, go to the source directory and type "make" and see what happens.
Underneath the hood, what happens is that "make" has a recipe file (probably called "Makefile", maybe generated through the autotools from "Makefile.in", which comes form "Makefile.am") and knows what target depends on what sources to get built, and where those sources are found. It tells the compiler, linker, archier, and other tools where to find the sources through a series of arguments passed on the command line to the tools. Those arguments differ for each tool, but in your case the search path for finding header files is augmented on the GCC command line with a "-I" argument, the search path for libraries passed to the linker tool is augemnted with the "-L" argument, and additional libraries are listed in search order with the "-l" (ell) arguement.
First, if you have surces shared between two programs, you should factor them into a library and share that library between programs. No copying, just simple compile-time dependencies. That's what libraries were invented for back when punched cards were in stylish vogue.
Second, and at least this used to be true and I think it still is, KDevelop is a gui interface around the de facto standard POSIX build system of using the "make" command-line tool to build programs. If you want to build your program from the command line, go to the source directory and type "make" and see what happens.
Underneath the hood, what happens is that "make" has a recipe file (probably called "Makefile", maybe generated through the autotools from "Makefile.in", which comes form "Makefile.am") and knows what target depends on what sources to get built, and where those sources are found. It tells the compiler, linker, archier, and other tools where to find the sources through a series of arguments passed on the command line to the tools. Those arguments differ for each tool, but in your case the search path for finding header files is augmented on the GCC command line with a "-I" argument, the search path for libraries passed to the linker tool is augemnted with the "-L" argument, and additional libraries are listed in search order with the "-l" (ell) arguement.
Well, as it has been said, the optimal solution is to make a shared li. I just want to add that you should discard Kdevelop and use scons building system. Could be rough in the beginning, but you get used to it quickly and get more control of building process.
I do have several shared files between my game and its editor, and as they reside both in the same directory it is trivial for me to keep a single copy of those files and both projects (game and editor) are built with a single SConstruct file.
I do have several shared files between my game and its editor, and as they reside both in the same directory it is trivial for me to keep a single copy of those files and both projects (game and editor) are built with a single SConstruct file.
You could also create links that point to the same source files. Once, I hear, it was common to have whole link farms, where whole projects were created by just putting a plethora of links into each.
Of course you have to be careful if you ever want to fork your project.
The library or dependency solution is of course definitely more elegant, but sometimes, linking is just the thing to KISS.
edit:One last thing: If you plan to port to mingw/cygwin, make sure you either don't change the files, or apply the changes to all copies, because otherwise mingw/cygwin will fork those files for you without giving notice.
Of course you have to be careful if you ever want to fork your project.
The library or dependency solution is of course definitely more elegant, but sometimes, linking is just the thing to KISS.
edit:One last thing: If you plan to port to mingw/cygwin, make sure you either don't change the files, or apply the changes to all copies, because otherwise mingw/cygwin will fork those files for you without giving notice.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
