You may think to put the macro to a header file, thus changing it will cause only the files that including that header being recompiled.

That was my first intention, but how do I have this macro beeing changed when I selected a different build configuration? I thought that whats the preprocessor-configuration option was for...

However, I do think you need a separate build configuration rather than using a macro.

Pretty much the same question as above: Even if I have a seperate build configuration, how would the correct API being choosen from the header files of the engine? On which API I use depends e.g. many typedefs for my interfaces, determining which type of low-level texture, mesh, etc.. wrapper is being used. With what you said first, is what I want to achieve even possible? I want to compile my engine into different libary files, and then in the project pick that correct implementation, which however does change how header files are laid out... does that even work with recompiling the engine?

The seperate build configuration approach. You have two build configuration. config9 and config11. In config9, you define API_DX9 in build configuration, in config11, you define API_DX11. Now to build different target, you just select different build configuration, no need to change the macro, so only part of the project will be recompiled.

I am already aware of that. If I didn't get it clear before, thats what I'm already doing. The problem is, that it won't work for a project outside of the solution the engine is in, whether I select a seperate configuration or manually define the macro. If I define e.g. USE_API_DX11 in the main.cpp-file of an app that uses the engine , it will work for a project that is inside the same solution as the engine. Any other project however, in a seperate solution, the so defined macro (whether macro or build config) won't be seen by the engine. And I do need to have the correct macro defined outside of the engine for the correct headers and interface implementations to be selected. Any ideas how to solve this?

Then the project that uses your engine has to define the macro in build configuration, or define the macro before include any headers in your engine. There is no better choice, IMHO.

Unfortunately, thats exactly what already happend. But as I described, no matter how I define the macro in the other project, if that project is in another solution, it won't work. Only for projects in the very same solution as the engine, defining the macro works. I still have to define the macro in the using project, but there it works, even if the main.cpp-code is 1:1 the same. Thats the odd thing, I'm pretty sure I'm theoretically doing everything right, but that little difference of where the project is, decided whether macro definition will work, or simply be ignored. :/

1, Auto detect which DX version to use, if there is any version related macro in DX headers, maybe you can use it? I'm not sure if it's possible because I never used DX.

Thats not really possible though, mainly because I'm on for a multi-api-support approach, and secondly because DX includes all three versions in pretty much the same location - the engine picks the correct header, based on the USE_API macro...

2, Change the headers in your engine DX agnostic. Thus your engine only exposes one single interface to the users. This is better API design and how a lot of cross platform open source projects do.

How is that supposed to work? Since my API-wrapper is compile-time dependand on which API to use, I need to e.g. typedef which version of my dx-wrapper the api-agnostic gfx-layers should use:

#pragma once
#ifdef USE_API_DX11
#define ACL_API_DX11

#pragma comment(lib, "d3d11.lib")
#pragma comment(lib, "d3dx11d.lib")
#pragma comment(lib, "dxguid.lib")
#pragma comment(lib, "D3Dcompiler.lib")
#pragma comment(lib, "dxgi.lib")

#pragma warning(disable:4005)

namespace acl
{
	namespace dx11
	{
		namespace d3d
		{
			class Device;
			class Sprite;
			class Texture;
			class VertexBuffer;
			class Effect;
			class Mesh;
			class Font;
			class DepthBuffer;
			class Line;
			class ConstantBuffer;
		}
	}

	typedef dx11::d3d::Device AclDevice; 
	typedef dx11::d3d::Sprite AclSprite;
	typedef dx11::d3d::Texture AclTexture;
	typedef dx11::d3d::DepthBuffer AclDepth;
	typedef dx11::d3d::VertexBuffer AclVertexBuffer;
    typedef dx11::d3d::Effect AclEffect;
    typedef dx11::d3d::Mesh AclMesh;
    typedef dx11::d3d::Font AclFont;
	typedef dx11::d3d::Line AclLine;
	typedef dx11::d3d::ConstantBuffer AclCbuffer;

}

#endif

How am I supposed to get that away from the headers, without using an interface for that low level classes (would affect performance in my render queues in a bad way, plus possibly violate multiple SOLID rules...)?