Hi folks,
I'm building a library A which calls functions in library B. A depends on B.
I'm making an application P which calls functions in library A. That is, P depends on A. I want to arrange things so that P depends only on A, and P does not depend on B. How do I arrange this?
This is C++ on Visual Studio 2008. I get the impression that when I build A, devstudio ignores the setting in librarian - general - link library dependencies and copies anything it can into A from other libraries. What is meant to happen?
If you want P not to depend on B you have to copy the code from B into A but why is the dependency chain an issue at all?
No VS doesn't copy anything from one library to another. Why do you think it does that?
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
No VS doesn't copy anything from one library to another. Why do you think it does that?
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
These two points clearly demonstrate that project A is copying B's code and putting it into A.
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
These two points clearly demonstrate that project A is copying B's code and putting it into A.
In the end, the linker is going to need all the code necessary to build the final executable. You either pay for it now by making A bigger by including B , or pay for it later by specifying A and B when you build your application.
As to your question, either
1) make sure that modules in A do not call any modules in B, or
2) take the source code from B, add it to the project that builds A, and then you only have A to build.
In the end, the linker is going to need all the code necessary to build the final executable. You either pay for it now by making A bigger by including B , or pay for it later by specifying A and B when you build your application.
As to your question, either
1) make sure that modules in A do not call any modules in B, or
2) take the source code from B, add it to the project that builds A, and then you only have A to build.
Regards,
Paul McKenzie
indeed, Paul, but you're not answering my questions. (1) is not going to happen. (2) is not viable either.
Last edited by c94wjpn; March 29th, 2012 at 11:29 AM.
Well you didn't mention that you actually linked A source with B library but yes in that case that's what will happen.
The "normal" way to do it is to create A and B as separate libraries and leave the linking to when P is built. "Normal" since everything depends on what you actually want to do...
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
I want to arrange things so that P depends only on A, and P does not depend on B. How do I arrange this?
Do you mean (a) actually getting rid of the dependency between P and B or are you just asking (b) how to prevent having to include B.lib in project P (or (c) add a dependency between projects P and B) in your solution? Note that in (b) or (c) P is still dependent on B.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
Do you mean (a) actually getting rid of the dependency between P and B or are you just asking (b) how to prevent having to include B.lib in project P (or (c) add a dependency between projects P and B) in your solution? Note that in (b) or (c) P is still dependent on B.
b is what I'm aiming for. I seem to have achieved this, but I'd like confirmation that I'm doing it the right way: how do I build A.lib so as it copies everything it needs from B?
Further, will I get linker errors if someone (not me) then builds P against A.lib and B.lib?
Please see the simplistic sample I made. It presumably imitates your case. Try to analyze two ways of building A and see the difference in A internals as well as resultant .exe dependencies on libs.
So, no comments, no questions? Seems I need to add some more to my last reply.
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
This means that librarian extracts all required objects from B and archives them to A.
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
Of course it will. Remember, A depends on B, and when building P all the external dependencies, direct or indirect, need to be resolved.
There are two situations possible with P, A and B successful build:
Prerequisite: Library A functions require some functions from library B.
1. A is built extracting required functions from library B. Executable P depends only on functions from library A (as the one already includes all necessary functions from B). Once A is built this way, P never needs B to be included to the project. Please note, in this case A needs B to be included in A project.
2. Library A is build without including B in A project, so it contains references to B functions unresolved. In this case when linking P, functions from A still need the functions from B to be resolved, and this results in extra dependency on B for P. Please note, in this case P needs B to be included in P project.
In first case rebuilding A will need path to B to be known in A project. Rebuilding P will depend only on path to A.
In second case rebuilding P will need both A and B path to be known in P project.
In both cases some indirect or direct dependency on B exists. Just because A functions depend on B functions. The only way to eliminate dependency on B is moving B source code to A. This is what Paul already mentioned before.
These two points clearly demonstrate that project A is copying B's code and putting it into A.
Well, rephrasing you, object code from B appears archived to library A. Yes, that's right.
I want to arrange things so that P depends only on A, and P does not depend on B. How do I arrange this?
You already did. P depends only on A. If you never rebuild A, P is going to build with no problem ever.
So, no comments, no questions? Seems I need to add some more to my last reply.
This means that librarian extracts all required objects from B and archives them to A.
Of course it will. Remember, A depends on B, and when building P all the external dependencies, direct or indirect, need to be resolved.
you miss the point of my statement "if I build app P against A, it will only do so successfully if project A knows about B's library files." To make it clearer for you, perhaps I should state it thus: "I build app P against A and only A. P builds successfully if A knows about B. It does not build if A does not know about B."
Further, no-one has commented yet on the purpose of the "link library dependencies" option.
Last edited by c94wjpn; April 3rd, 2012 at 03:28 AM.
you miss the point of my statement "if I build app P against A, it will only do so successfully if project A knows about B's library files." To make it clearer for you, perhaps I should state it thus: "I build app P against A and only A. P builds successfully if A knows about B. It does not build if A does not know about B."
No I do not miss anything. In case your library A does not archive required objects from B, it is naturally for P build to fail. Please re-read my comments carefully.
No I do not miss anything. In case your library A does not archive required objects from B, it is naturally for P build to fail. Please re-read my comments carefully.
... you missed the bit that said
Further, no-one has commented yet on the purpose of the "link library dependencies" option.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.