Differencebetween "Include Directories" and "Additional Include Directories"

What is the difference between Include Directories and Additional Include Directories

This is awkwardness that got introduced in VS2010. The VC++ Directories settings used to be located in Tools + Options, Projects and Solutions, VC++ Directories. Global settings that applied to every project that was built on the machine. It is still there but points out that you should now change it in your project settings. A side-effect of the build engine overhaul in VS2010, enabling building with msbuild. Removing the per-project settings would have been logical but that would break too many existing projects.

As such, it is probably best to treat the VC++ Directories settings as the machine default. It is automatically preset by the VS installer. Tinker with it only if you need an unusual directory search order, putting the custom locations last. Very unusual to do so.

It does work however. And it did get taken advantage of eventually. Empowering the Platform Toolset setting in VS2012 and up. Different compiler, different linker, different #include directories, different linker search path. Modified with just one setting, nice.

What is the difference of Additonal Include Directories and Additional #using Directories?

#using is for C++/CLI, not for standard C++.

A directory to search to resolve file references passed to the #using Directive directive.

assembly_A.cpp

// compile with: /clr /LD  
public ref class A {};

assembly_B.cpp

// compile with: /clr /LD  
#using "assembly_A.dll"  
public ref class B {  
public:  
   void Test(A a) {}  
   void Test() {}  
};

The option /AI[path] would set a search path where assembly_A.dll is placed.

More official info: VCCLCompilerTool.AdditionalUsingDirectories Property

What is the difference between include_directories and target_include_directories in CMake?

include_directories(x/y) affects directory scope. All targets in this CMakeList, as well as those in all subdirectories added after the point of its call, will have the path x/y added to their include path.

target_include_directories(t x/y) has target scope—it adds x/y to the include path for target t.

You want the former one if all of your targets use the include directories in question. You want the latter one if the path is specific to a target, or if you want finer control of the path's visibility. The latter comes from the fact that target_include_directories() supports the PRIVATE, PUBLIC, and INTERFACE qualifiers.

MSVC use additional include directories of referenced static library project

No. There is no way to automatically add the folders.

(step 5 in Walkthrough: Create and use a static library - Use the functionality from the static library in the app)

To include a header file (listed in the additional include folders) you need to use <... >

#include <header.h++>

Additional include directories in Visual Studio for C++

Your problem is that the "A" directory is not inside the "B" directory, and the line #include <A/Aa/Aaa.h> looks for the path you gave starting from the current directory, so it's looking for: "B/Bb/A/Aa/Aaa.h" To resolve this, you can do one of two things.

Indicate the actual location of the Aaa.h (relative to Bbb.h) file in the include statement: #include "../../A/Aa/Aaa.h>" (Using such relative paths, however, will generate warnings in many compilers, as they aren't really portable.)
Add the directory (again, relative to the project) in the list of include folders as "../../A/Aa" and then just give the filename in the include line: #include "Aaa.h" (To avoid any confusion with typing in the directory path, you can just 'browse' for the actual folder from the "Properties" pop-up.)

PS: Though not strictly enforced, the custom is to use the < > 'quotes' for header files in system directories (like #include <iostream>) and traditional quotes for user-supplied headers (like #include "Bbb.h").

What is the difference between VC++ project lib directories and linker inputs

This setting got fumbled a bit in VS2010, it was much clearer in previous versions. Where the settings you show in your screenshot were present in Tools + Options. Which shows the core intent, they contain directories that are determined by the setup for Visual Studio and its components. The locations of the CRT, MFC, ATL and SDK libraries.

The Linker + Input + Additional Dependencies setting is the important one, there you say exactly what .lib files the linker should link. You can specify the path of a .lib file and be done. But it is not uncommon that you only specify the name of the .lib file, then edit Additional Library Directories to tell the linker where to search for those .lib files. Which is handy if the install location for, say, Boost isn't always the same or you want to switch from one version of Boost to another.

So in summary:

Linker + Input + Additional Dependencies: add the .lib files you need to link
Linker + General + Additional Library Directories: only use if you didn't specify the path of .libs
VC++ directories: don't mess with it

Do note that the last two bullets only specify directories, not .lib files that the linker should link. The first bullet specifies actual .lib files. What is invariably confusing to starting MSVC programmers is that the linker magically knows how to find important .lib files without specifying them explicitly in the Additional Dependencies setting.

That's unfortunately the non-visual part of Visual C++. There are two distinct ways in which a project can specify .lib files that the linker should link without using the setting. The first one is the project template you selected to get the project started. It uses project property sheets, files that specify default settings for a project. You see them with View = Other Windows + Property Manager. An important one is "Core Windows Libraries", it sets the Additional Dependencies setting to link the essential Windows .lib files, the ones you always need like kernel32.lib and user32.lib. Those settings are "inherited" by your project. Otherwise giving meaning to "NoInherit" if you ever run into it.

The second important way is the #pragma comment directive. Which is used in source code, it injects a linker directive. The "lib" variety is important, that tells the linker to link a .lib file. In addition to what you explicitly specify in the linker's Additional Dependencies setting. A very good example of that one is vc/atlmfc/include/afx.h. Search for "#pragma comment". Note the macro soup that selects the proper mfc .lib file, depending on compiler specific settings. And the bunch of extra Windows .lib files an MFC needs to link.

The C++ build model is filled with a maze of twisty little passages. The IDE tries to make you fall in the pit of success but in the process hides what's important to get to the next level of understanding. It isn't different in C#, to know how to make the Reverse() extension method not consume O(n) storage requires digging in.