Re: Singleton MFC Extension DLL
"Ajay Kalra" <email@example.com> wrote in message
It works beautifully in this case. If your .lib changes and you rebuild
lib project only, the next time you build the .exe which depends on it it
will see the .lib has changed and relink. It's even better. If you
a .cpp file in the .lib and rebuild the .exe, it will first build the
then build the .exe. It's all as it should be.
I agree that it works(I havent verfified it) but the behavior you
described is no different than if you explicitly put it the lib as on
the input libs. No?
It's different in the case where you change a .cpp file in the .lib and then
build your .exe. If the .exe doesn't have a project dependency on the .lib
(but just has the .lib on the linker line), then building the .exe will
erroneously not build the .lib first. However, if the .exe does have a
project dependency on the .lib, then the .lib will be built before the .exe.
So having the project dependency helps when you are actively editing the
dependent modules like the .lib simultaneously with the caller of it like
the .exe. Sometimes this is done quite often, so project dependencies
really simplify things. Really, the concept of the .sln is incomplete
without the additional concept of project dependencies because without that,
Build Solution really has no meaning. For one thing, the dependencies
define the build order of the solution so that the module with no
dependencies on the rest of the solution is built first.
I can see where like Stephen says it makes the .sln file a key player such
that .vcproj files are not standalone anymore, so in this case it is also
helpful to put the .lib in the linker line also. But most of my projects
are small such that I only use one .sln, and for me, adding the .lib to the
linker line is superfluous. Regardless, the proper Project Dependencies
must be set up.