Library linking

Introduce your project and write about your work.

Moderator: PPS-Leaders

Post Reply
User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Library linking

Post by 1337 » Thu Nov 29, 2007 4:56 pm

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

Every single subfolder, or just the folders in src?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Thu Nov 29, 2007 7:39 pm

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.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Sun Dec 02, 2007 11:41 am

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?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Sun Dec 02, 2007 4:17 pm

1337 wrote:As I understand it, this game should run under windows too, right?
Yes, of course. Most gamers use windows.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Tue Dec 04, 2007 1:55 pm

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.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Tue Dec 04, 2007 8:49 pm

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.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Wed Dec 05, 2007 1:15 pm

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.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests