[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:
Related
related to SERVER-49703 Add alphabetic lib ordering libdep li... Closed
related to SERVER-49760 Add lint-public-libdeps-prohibited to... Closed
related to SERVER-49761 Add lint-libdeps-leaf-node to libdeps... Closed
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:

  • We should only allow one of LIBDEPS or LIBDEPS_PRIVATE on anything that is a Program. Since things don't link to Program nodes, it doesn't matter which, but there is no advantage to declaring them one way or the other. Since LIBDEPS_PRIVATE doesn't really mean anything (or LIBDEPS_INTERFACE for that matter), we should disallow use of all forms other than LIBDEPS on things that are {{Program}}s.
  • We have a facility for injecting reverse dependency edges via [PROG|LIB]DEPS_DEPENDENTS. An injectable library by definition adds behavior that may or may not be present. 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.
  • Continuing with DEPS_DEPENDENTS, with the above rule enforced, it doesn't make sense for any Library that declares itself to function via reverse dependency edges to have anything other than LIBDEPS_PRIVATE dependencies, since if the injectable library is truly optional, it cannot be the source of any resolved symbols.
  • If it is not currently enforced, we should ensure that for a given Program or Library, that any other library is listed exactly once among its LIBDEPS, LIBDEPS_PRIVATE, and LIBDEPS_INTERFACE sections.

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: SERVER-48638 added missing quote to error message
Branch: master
https://github.com/mongodb/mongo/commit/ecd1e0b022a68110ada6517f84ffd91ea8a91bca

Comment by Githook User [ 23/Jul/20 ]

Author:

{'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'}

Message: SERVER-48638 Added LibdepsLinter to enforce LIBDEPS rules
Branch: master
https://github.com/mongodb/mongo/commit/d986854f5ec4fda16d22baab2d380b202626661f

Comment by Githook User [ 23/Jul/20 ]

Author:

{'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'}

Message: SERVER-48638 Added LibdepsLinter to enforce LIBDEPS rules
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/22e64080b563ee5e15ffdda5a408f43fc838917a

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?

Generated at Thu Feb 08 05:17:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.