C++ Visual Studio - multi-project solution - "static lib" vs "include directories"

Question

I am trying to set up a multi-project solution using static libraries in Visual Studio.

As an example, the project OtherProject contains the class Foo situated in Foo.h, which I would like to use in the project MyProject.

From what I have understood, to accomplish this using static libraries I have to:

1. In OtherProject change "Configuration Type" to "Static library (.lib)".
2. In MyProject.
   1. In "Common Properties -> Framwork and Referencees" Add New Reference to OtherProject
   2. In "VC++ Directories"
      1. In "Include Directories" add path to OtherProject's header files.
      2. In "Library Directories" add path from OtherProject to the created "OtherProject.lib".
   3. In "Input>Additional Dependencies" add "OtherProject.lib". (Edit) This step appears to be unnecessary and is made implicitly during 2.1 (thanks to @JBentley for pointing it out).
3. "Solution Properties -> Common Properites -> Project Dependencies", chose MyProject in dropdown and add dependency to OtherProject. (Edit) This is unnecessary, and is made implicitly in step 2.1 (also @JBentley).

...and everything should be peachy. However, if I skip everything above and only include the source files of OtherProject, like this:

1. In MyProject "VC++ Directories -> Include Directories" add path to OtherProject header files (and possible source files as well?).

...everything appears to be working like before, and with much less work.

My test file in MyProject looks like this:

#include <OtherProject/Foo.h>

int main()
{
    Foo foo;
    return 0;
}

Questions

• Does my "Static Library" approach appear to be valid, or may I run into problems later on?
• Is the second approach valid? Will it create problems later? I guess one cons is that I cannot hide part of the implementation in a lib file, and have to supply both source and header instead of lib and header.
• Is there any pros and cons of each methods?

(Edit) The following question is about a similar problem: Link libraries with dependencies in Visual C++ without getting LNK4006. It appears Visual Studio is smart enough to take care of some of some of the steps I listed, and avoiding the unnecessary steps appears to get rid of "LNK4006 second definition ignored" I was having further down the line:

Answer 1

Does my "Static Library" approach appear to be valid, or may I run into problems later on?

Looks about right. Can't see anything that would cause a problem (other than if you start moving directories around, etc).

Debugging may be hindered by the lack of source code for Foo's implementation, making it harder to use. Of course, you can always supply the source file and a debug build of the library, in which case this particular problem "goes away".

Is the second approach valid? Will it create problems later? I guess one cons is that I cannot hide part of the implementation in a lib file, and have to supply both source and header instead of lib and header.

Would be valid (in the sense that you can include other source code from another project into your current project - it's no longer, technically, a "static library"), yes (the user may need to add the Foo.cpp file to the project as well - and any other file that the project includes. If Foo and it's parts is a lot of files, this could be a major drawback.

Aside from having to supply sources, you also increase the compile time for the entire project (at least when built from scratch). This may not be an issue for a small project, but larger projects can take quite some time to build.

A plus is of course that the user of the functinality in class Foo can step into the source and debug it when something goes wrong.

Is there any pros and cons of each methods?

Answered above, I think.

Answer 2

Your second approach is not quite valid in the sense that you are not really creating a static library. You just have your OtherProject sources in a different directory but being built as part of MyProject.

So if you truly want to create a static library to hide the implementation, you have to do the "extra" steps. There is no shortcut.