# Different output lib file based on #define

This topic is 1745 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello,

I'm using Visual Studio 2012 to compile my engine/game framework to a static lib file. I support different APIs, like DX9 and DX11. Those are choosen via a #define. Only problem is, whenever switching between those two, my whole libary has to be recompiled. Is there any way to ouptut to differnent lib files, say. Engine9.lib if API_DX9 is defined, and Engine11.lib if API_DX11 is defined?

##### Share on other sites

Usually you would use a separate build configuration for that...

##### Share on other sites

Ah, that seems like the way to it. Now I only have one tiny problem left. So I made 4 different configurations: DebugX9, DebugX11, ReleaseX9, ReleaseX11. As for now, every single build outputs the libary to another directory. I tried changing the directory in the settings page for every configuration from "$(SolutionDir)$(Configuration)\" to "$(SolutionDir)Debug\" or "$(SolutionDir)Release\", however when applying the settings, it will always reverse my changes. Do I have to do this differently, or do you have any idea whats wrong here?

##### Share on other sites

Nope, dunno what is going on there. There is an "all configurations" drop down which may work? Have you changed the output .lib name to be different for each configuration (if they are all the same it could decide you want them in different directories? Perhaps...).

If all else fails use a post-build step to copy the lib where you want it.

##### Share on other sites

Never had an issue with it reverting changes. Just be sure to change the "Output Directory"/OutDir and "Target Name"/TargetName (forget the exact list applicable to .lib files, but there may be more than just the .lib itself you don't want to collide, which should by default be in therms of $(OutDir) and$(TargetName)). You could also have the configuration specify the define (C/C++ -> Preprocessor), not sure how your doing it currently without a config, assume your not editing a header before each build?

Edited by SyncViews

##### Share on other sites

Nope, dunno what is going on there. There is an "all configurations" drop down which may work? Have you changed the output .lib name to be different for each configuration (if they are all the same it could decide you want them in different directories? Perhaps...).

Yes, this drop down is there, but it doesn't work eigther. I have selected a different lib file, with an X9/X11 and a d if its debug, so its very strange... I'll look into it more deeply, considering the post-build step, but for now I've run into a far more delicate problem which actually causes external projects not to compile anymore.

So, I have a file like this:

#pragma once

#ifdef USE_API_DX9
#include "DX9\Def.h"
#else
#ifdef USE_API_DX11
#include "DX11\Def.h"
#else
#error "No api selected"
#endif
#endif

#if defined(USE_API_DX9) && defined(USE_API_DX11)
#error "Can only use one graphics API at a time."
#endif


Which selects the correct include-file for compile-time dependency of the API. Now, I used to manually define the USE_API_XXX at the top of this file before, which worked fine. Now I've included it under C++/Preprocessor/Preprocessor definitions, depending on the selected build configuration. Now all I have to do is e.g. USE_API_DX11 at the top of my main-file, and it selected the correct api:

#define USE_API_DX9

#include "Engine.h"
#include "MainState.h"

// Windows main-Funktion
int WINAPI WinMain(HINSTANCE hInstance,      // Handle der Programminstanz
HINSTANCE hPrevInstance,  // Handle der letzten Instanz
LPSTR lpCmdLine,          // Kommandozeile
int nCmdShow)             // Art wie das Fenster angezeigt werden soll
{

AclEngine engine(hInstance);

engine.Run<acl::MainState>();

return 0;
}


Strangely enough, this only works for projects in the same solution as the libary. For any other project, that is part of a seperate solution, it will fail with the first error of my ApiDef-file, as for some reason the define seems to not being carried through far enough. Exactly the same code, just a different solution, and it isn't working. Any idea how to solve that?

##### Share on other sites

You can probably do that with property sheets? I don't normally deal with those so I'm not sure.

Things get a bit awkward if you use multiple solution files, it is much easier to use one solution and have lots of projects in the solution, if you can.

##### Share on other sites

Things get a bit awkward if you use multiple solution files, it is much easier to use one solution and have lots of projects in the solution, if you can.

Well, since I'm creating an engine that might be used by some people other than me; and since I want/need to have my projectes decoupled as much as possible from the engine (due to having projects in my studies not directly related to, but build using the engine); up until the point where I go unity-like without requiring to directly programm anything for a new game, I'm somewhat required to support building from different solution files. Any pointers on what options I have to make this possible (using defines across multiple solution files, or any other possibility)?

##### Share on other sites

All the engines I have used have been in-house (and for consoles not PC), so I dunno.

You could set environment variables perhaps, if your settings change rarely. Are users going to build against different versions of the DirectX API? If not, environment variables could be the way to go.

##### Share on other sites

You could set environment variables perhaps, if your settings change rarely. Are users going to build against different versions of the DirectX API? If not, environment variables could be the way to go.

Yes, the engine is intentended to be used in games build against different versions of the DX-API, it pretty much allows a game to run on different APIs just by changing a compile time switch. So I don't think an environment variable would be sutable here (though I might want to check them out for making the setup of a new project easier, using them for the engines include path). Any other suggestions what I might use instead? Just a quick note, it's funny though, isn't the compiler supposed to more or less just stick the header files together, so I don't really see where the big difference in preprocessor defines in eigther the same or another solution comes from...?

• 10
• 17
• 9
• 14
• 41