0

Currently my visual studio is basically generating Engine.dll and Game.exe

Engine.dll links to some other basic libraries like: d3dx9d.lib ComCtl32.lib WinMM.lib WSock32.lib etc.

I also wanted to try to create an Engine.lib, but I get some really nice warnings now: Symbol x has been defined already. These libraries define the same symbols.

So I read somewhere that I must force my user (Game.exe) to link to the libs instead. But this is just really inconvenient I think, especially if I have many games and I decide to add another library to my engine. It's just maintenance for something so simple.

Should I stick to the .dll, or is there some way to fix this beauty up?

Thanks a lot,

Antoon

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Tony
  • 417
  • 4
  • 11

3 Answers3

2

You need to make up your mind whether the want the DLL or the static link library. Advantage of a DLL is that the build times can be quicker if you make local changes. Advantage of a .lib is that you'll end up with only one deployable file.

Getting it linked (either the static .lib or the dll's import .lib) is otherwise automatic. You want to make sure that the library is built first, can't link the .exe without it. Right-click the exe project in the Solution Explorer window, Project Dependencies, tick the library project. That automatically adds the .lib to the exe project's additional dependencies.

Using #pragma comment(lib, "engine.lib") in the engine's header file is another way. Repeat for other dependencies like the OS import libraries. Getting the library path right is a // todo item.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

Did you create a different namespace to avoid naming clashes?

EDIT -- seems like there is some confusion as to what you're asking, because you are asking a couple of questions.

To me, it sounds like you want to take a stab at implementing your own Engine class. However, you've got naming issues. I am treating this as more of an architectural question now. If you write your Game to an interface, then the problem goes away. For example, if your Engine is using different algorithms, then if you had written an EngineInterface that the current Engine and YourEngine implemented, then you could easily use Strategy to flip between the different implementations on the fly. This is nice because you'll be able to see the differences in-game if you wire the preferences into the app.

Dave
  • 14,618
  • 13
  • 91
  • 145
  • You mean I should completely wrap the libs and make them unneeded for users? – Tony Dec 28 '10 at 15:17
  • I'm just saying that if your application calls into an interface rather something that's concrete, the underlying implementation is irrelevant. You can wrap d3dx9d, winmm, etc in the current Engine DLL, but you could use opengl in MyEngine DLL. The application (what is essentially the "user") shouldn't care. – Dave Dec 28 '10 at 17:15
0

If the symbols are not supposed to be the same, use diferent names or control how they are exposed. Another option is the usage of namespaces to avoid naming conflicts.

If the symbols are supposed to be the same thing, you need to define those only once in one of the libs.

bcsanches
  • 2,362
  • 21
  • 32