[SERVER-48638] Enforce more rules for LIBDEPS Created: 06/Jun/20 Updated: 15/Aug/20 Resolved: 24/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | Daniel Moody |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Dev Platform 2020-07-13, Dev Platform 2020-07-27 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
We don't restrict LIBDEPS usage much, but we probably should. At least the following should probably be disallowed:
While working on the above, we should also investigate any use of DEPS_DEPENDENTS in the community repo, as it is somewhat unclear what purpose they serve. |
| Comments |
| Comment by Githook User [ 15/Aug/20 ] |
|
Author: {'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'}Message: |
| Comment by Githook User [ 23/Jul/20 ] |
|
Author: {'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'}Message: |
| Comment by Githook User [ 23/Jul/20 ] |
|
Author: {'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'}Message: |
| Comment by Andrew Morrow (Inactive) [ 10/Jul/20 ] |
|
daniel.moody - That might be one way to achieve that restriction. Another, which had been my original hand-wavy idea, would be to split library libx into two new libraries. The bulk of libx would remain as is, and liba would continue to depend on it the normal way. And then there would be a new, little library liby, that depended on libx and was injected into libb via DEPS_DEPENDENTS. And then we would enforce that because liby had DEPS_DEPENDENTS, it was prohibited from being the target of any LIBDEP declaration. I think the advantage of doing it that way (though I haven't fully thought it through) would be that we wouldn't need to add a lot of new DEPS_DEPENDENTS declarations. They are unusual and most developers aren't very familiar with them. I think both approaches could work though. Overall, I think this particular restriction should wait until last, as I think it is the most complex. |
| Comment by Daniel Moody [ 10/Jul/20 ] |
|
we should disallow linking directly to nodes that use DEPS_DEPENDENTS, since if that happens the node participates in both the forward and reverse sense, which is very confusing.
So a given library A, that is linking directly to node X, where node X is using DEPS_DEPENDENTS for reverse dependency to library B, library A should instead of direct linking, be listed as a reverse dependency on node X as well? |