On 09/09/14 11:18, Gao, Liming wrote: > Tools behavior tries to avoid the cycle between the library > instances. From Library INF file, some ones depend on each other, but > their constructor may have no dependency. If they are all considered > even if they have no constructor, the cycle will easily happen, and > cause tools break. So, BaseTools cares the library instance with the > constructor. I agree it is not accurate, because INF file has no > information to describe the library constructor dependency. For the > failure case, we have to add the empty constructor function as its > constructor to resolve the real dependency issue. > > For your case, I prefer to resolve the real dependency issue. Is the > change for BaseOrderedCollectionRedBlackTreeLib enough? If yes, I > suggest to only make this change now. If you add more dummy > constructor functions, it may cause the cycle dependency happen.
This patchset does not address any current problems. I wrote it out of pure caution. I think I understand the issue. Constructors are all-or-nothing. That is, we can't express that a library's constructor depends only on a *subset* of the library's complete set of (runtime) dependencies. Hence, if you add a CONSTRUCTOR to the INF, it might create false init-time dependencies, leading to false cycles, breaking the build unnecessarily. The only way out of this is to omit CONSTRUCTOR from one of the library instances that constitutes the cycle (which will then imply that this library will be initialized as the first one). And then it is the programmer's responsibility to ensure that this library instance in fact impose no direct or indirect init-time dependencies. Okay. Our original problem (independent of this series) was that we just copied (and customized) a library instance that had no CONSTRUCTOR. Our customized version *did* impose (indirect) init-time dependencies, but we didn't notice. Obviously, this library would then be initialized first, and due to the indirect init-time dependencies that we gave it unknowingly, it would crash. Once we realized those dependencies, we added the CONSTRUCTOR, and then the cycle was laid bare. Given that the cycle was *valid*, we addressed the cycle itself, by reorganizing the code, and removing some dependencies for real. My point here is that adding empty constructors immediately at the beginning is *safer*. They cause no problems until they suddenly cause problems -- and when they do, you get a cycle report, and you can work to address the cycle. You can analyze if the dependencies are valid or false. You can split up libraries, create customized copies without dependencies / CONSTRUCTORs, and so on. Whereas, if by default you don't add constructors, then the sudden breakage will not present itself as a nice controlled cycle report. It will show up as a crash, at runtime. You say that you'd prefer to resolve the real dependency issue. We have none, currently. But what speaks against the safer approach, ie. adding all the empty constructors now, and resolving the real dependency issue (*or* the false cycle report) when there is a cycle report? This is a tradeoff between false cycle reports and runtime crashes. - With empty constructors added by default, you get valid cycle reports, and you get false cycle reports. - With empty constructors *omitted* by default, you get valid cycle reports, and you get runtime crashes. Am I wrong? Thanks, Laszlo ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
