CODEWITHSUNDEEP
visual-studio-2013linker
codekiddy
codekiddy

Reputation: 6137

Link library in Visual Studio, why two different ways?

I need to link library from one project into another, and it looks there are 2 ways, can you tell what is the difference and what is the consequence of having "true" in one setting and "false" in another (the same) setting?:

enter image description here

and another one: enter image description here

What is the difference, and do I need both setting set to "yes" or just one and if so which one?

Upvotes: 6

Views: 3984

Answers (2)

bogdan
bogdan

Reputation: 9317

A one-line explanation would probably be that the second option specifies something about how the first one works.

  • Link Library Dependencies set to Yes: if the solution is set up so that the current project has a dependency on another project that produces a .lib file, then that file will be linked in automatically.
  • Use Library Dependency Inputs set to Yes: useful when Incremental Linking is enabled. Normally, if a .lib generated by another project changes, and the current project depends on it, the linker can no longer link the current project incrementally (it's difficult for it to know how exactly the .lib changed). If you set this option to Yes, then the linker doesn't use the .lib file generated for the other project, but rather the individual .obj files that were used by the librarian to generate that .lib (as if the .lib didn't exist, and every object file from the other project were given to the linker individually, alongside the .obj files from the current project). This enables it to continue linking incrementally when faced with changes in .lib dependencies.

As far as I can tell, Use Library Dependency Inputs only makes sense if Enable Incremental Linking is also set to Yes, and the current project depends on another project that generates a .lib file that changes often during development.

Conversely, Enable Incremental Linking can be set to Yes without enabling Use Library Dependency Inputs, in which case the project will be linked incrementally as long as .lib dependencies don't change; when such a change occurs, the linker will fall back to a full link for that particular build.

Additional information here and reference docs here.

UPDATE based on OP's comment:

As far as I can tell, the property entry under Project Reference Properties specifies the setting individually for each referenced project (whether to use the .lib from that specific project or not), while the one under Linker - General is the default setting for referenced projects.

For example, if you set the one under Linker - General to No and add a new referenced project, then, for that project, the setting under Project Reference Properties will default to False. However, the settings for referenced projects that were added before keep their individual setting.

I expect the individual setting under Project Reference Properties to override the default from Linker - General, but I haven't actually tested this bit.

Upvotes: 9

0xC0000022L
0xC0000022L

Reputation: 21369

Since I don't want to hijack the existing excellent answer by bogdan, I wanted to add one minor aspect.

The above settings exists in the .vcxproj file inside an ItemDefinitionGroup, keyed to a particular project configuration.

<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='...|...'">
  <ProjectReference>
    <LinkLibraryDependencies>true</LinkLibraryDependencies>
    <UseLibraryDependencyInputs>false</UseLibraryDependencyInputs>
  </ProjectReference>
</ItemDefinitionGroup>

As one would think, the value here can be true or false for the two item definitions. The item definition group establishes the default settings for tasks within a project file. So this establishes the settings for the ProjectReference task. Consequently an ItemGroup for ProjectReference also follows further down in the .vcxproj, listing the actual project dependencies with GUID etc.

I always find it useful to be able to match the setting in the IDE to the XML element in the project files, because it enables me to grep for the settings across entire directory hierarchies.

Hope someone else find it as useful.

PS: Unlike most "tool" settings in an ItemDefinitionGroup, LinkLibraryDependencies doesn't correspond to a command line switch. Instead it's MSBuild that conveys the list of compiler outputs between the dependent projects. UseLibraryDependencyInputs on the other end becomes the name of the library dependency on the linker command line in the current project.

Upvotes: 1

Related Questions