CODEWITHSUNDEEP
c++visual-studiovisual-c++msbuildlinker
Ibraim Ganiev
Ibraim Ganiev

Reputation: 9390

MSBuild relinks every native project after internal changes in native dependency dll

Let's imagine this situation: Project Foo compiles to Foo.dll and Foo.lib. Project Bar compiles to Bar.dll and references Foo as a dependency in VS project.

Now the problem: Almost every time I change internal details (Not API, not set of exported functions) of Foo.dll - Foo.lib gets updated, and Bar.dll gets relinked with new Foo.lib. If I turn on detailed output in VS I see:

Source compilation required: input C:\PROJECTS\FOO\RELEASEUNICODE\FOO.LIB is newer than output C:\PROJECTS\BAR\RELEASEUNICODE\BAR.DLL.

And next command starts link.exe to link new Bar.dll

The question: Why does this happen? I'm not really familiar with idea of lib file for dll (I haven't seen .a file for .so dynamic lib in linux), but isn't the main idea of dll file is to avoid any compile-time linking? Why does the lib file change every time I change internals of foo.dll ? Is there a way to avoid relinking of dependant library? In my project I have dozens of dlls depending on foo.dll, and every time I change 10 lines of code in foo.dll - all these dependencies endup relinked, and this takes a lot of time.

Upvotes: 1

Views: 121

Answers (1)

C.J.
C.J.

Reputation: 16081

MSBuild simply looks time stamps for when a file was modified. It isn't smart enough to know that no public API changed. So the rule that msbuild operates by is, if an input is newer, the dependent (in your case bar) will have to be rebuilt (in your case simply relinked).

I supposed if msbuild knew about api changes, it would have to parse all the code and keep some sort of database of the entire code, something that for a build is mostly unnecessary and very costly.

Upvotes: 3

Related Questions