Different output lib file based on #define

Started by
14 comments, last by Juliean 10 years, 8 months ago

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?

Advertisement

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

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

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?

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

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?


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?

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley


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)?

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley


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...?

This topic is closed to new replies.

Advertisement