2

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:

Community
  • 1
  • 1
Adelost
  • 2,343
  • 2
  • 23
  • 28
  • 1
    It's been a while since I've used VS property sheets, but I believe the point of references is that you can skip step 2.2.2 and 2.2.3 (MyProject should automatically link to the output of all referenced projects by default), and also step 3 (MyProject should automatically be dependent on OtherProject due to the reference), so that the only thing you need to do is provide the headers path. Explicitly linking to the static library is redundant. – JBentley Apr 20 '14 at 16:46
  • @JBentley It wold be great if it where true as it would save some time. However, if I skip 2.2.2 and 2.2.3 I don't know if the project is using the lib file or not. And if I skip 2.2.1 the "lib" cannot be found when I try to compile, so it appears to be essential when using lib files. However, you are right about 3, adding a reference appears to automatically add a project dependence. – Adelost Apr 21 '14 at 08:53
  • 1
    If your solution compiles and links, then the lib is being used correctly and you can skip 2.2.2 and 2.3 (I typo'd that as 2.2.3 in my previous comment). Note, that I did not (and do not) suggest skipping 2.2.1, since references do not take care of header include paths for you. – JBentley Apr 21 '14 at 10:47
  • @JBentley It's been a while since you wrote this, but you where right about 2.3 being taken care of in 2.1, and it helped me get rid of linker error "LNK4006 second definition ignored" I was having today. Here is a similar thread: "http://stackoverflow.com/questions/564872/link-libraries-with-dependencies-in-visual-c-without-getting-lnk4006" Tomek Szpakowic suggests the same thing as you, "VS (at least 2005 and newer) is simply smart enough to add all needed static libraries to linker command line." – Adelost May 14 '14 at 19:01

2 Answers2

3

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.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
1

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.

ap-osd
  • 2,624
  • 16
  • 16