Library linking

[1337]

I have just received a tip from bensch: link everything dynamically.
Question is: how much.

Every single subfolder, or just the folders in src?

[beni]

I'm not sure, why you have chosen that structure and on what it depends.
From my point of view, It shouldn't hurt to dynamically link the others (in the orxonox folder) as well.
Wouldn't we do that, then we must really talk again about which things should be outside and which inside. Also the world entities for instance will have to be outside.

[1337]

I have digged myself a little into that dynamic/shared. And I think dynamic/shared is the way to go, but with --no-undefined (telling the linker, that no undefined symbols are allowed).

Under windows with Visual Studio 8, I would have to make some modifications to the code in order to make every library dynamic (mainly __declspec(dllexport) ). I will do that once I've got a little bit more time.
As I understand it, this game should run under windows too, right?

[x3n]

As I understand it, this game should run under windows too, right?

Yes, of course. Most gamers use windows.

[1337]

I have done some research concerning dynamic link libraries (dll) under windows, which means I googlet

One result has quite an impact on our code: If you want to use a dll, you need to have a *.lib file, that contains all the symbols (eg. variables and functions). And in order to create such a static library file, you need to specify the necessary function with an attribute in the code. Fortunately, it is sufficient for the class definition:

class __declspec( dllexport) DoomsdayDevice {
};

But: Once you would like to use such a function, you need to import it:

class __declspec (dllimport) DoomsdayDevice {
};

--> Hence we need to define a preprocessor symbol to do that job, since we can include the same header file in the library, as well as in a program, where we want to use the library.

The Ogre developers of course had the same problem. Their solution is to always include a header file: "OgrePrerequisites.h", which includes "Platform.h", where the export/import symbol is defined.

This brings up another problem: Including header files in header files is a bad idea, unless you can't help it (e.g. you want to inherit from a class). The problem already came up in the network library: If you use it, you need to include its header files, and these contain files from the boost and enet library, which you don't want to link as well, since they're already linked to the network library.
So, in header files it is sufficient to have a simple prototype for each class used in the header file, if only used as a pointer:
class DoomsdayDevice;
class AnotherDevice;
etc.
Now, in this prerequisites file, all these prototypes are stored in for the entire library.

This concept also saves a lot of compile time.


--> Every subproject with its own library needs a "name_prerequisites.h" and a "name_platform.h" header file, or however you want to call the files, just be consistent.

[beni]

What about a even more global solution?
This sounds as if we basically need this platform distinction in nearly every file! Couldn't we define the platform on a higher basis like in cmake? Shouldn't we be able to set some variables which the preprocessor can use then?
I'm not sure, but I think I remember a lot of examples where not really additional includes were necessary for preprocessor variables. Correct me if I'm understanding something wrong there.

[1337]

Thing is: Platform.h is probably always necessary since there are a lot of platform dependant things.
I thought about global implementation: didn't come up with a solution for my part.

About the Prerequistes files: Forget that, we simply define that we don't have enough source code that requires too much time to compile. Reason is simple: I don't want to be the one to explicitly tell everyone how to do it and why.

And the dependency problem is not a problem actually.