[SERVER-49148] Implement a facility for safer environment modifications Created: 26/Jun/20  Updated: 27/Oct/23  Resolved: 27/Oct/23

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 6.0 Desired

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-49141 Coverity build of mongodb/mongo faili... Closed
Assigned Teams:
Server Development Platform
Backwards Compatibility: Fully Compatible
Participants:

 Description   

In SCons, it is very easy to make a mistake where when declaring a Program or Library, you inadvertently overwrite an existing environment customization.

The problem is fairly obvious at a glance when you write something like:

my_env = env.Clone()
my_env.AppendUnique(LIBSDEPS=['a'])
my_env.Library(
    target="some_lib",
    source=["some_lib.cpp"],
    LIBDEPS=['b'],
)

Because you can see by inspection that the LIBS kwarg to my_env.Library will overwrite the value of LIBS that was applied after cloning the Environment. Even though it is obvious, it can still be surprising to developers who are not familiar with the fact that kwargs-style arguments in a Builder call are overwriting.

However, in cases where the Environment modification is programmatic, like with InjectThirdParty it can be very hard to spot the error:

my_env = env.Clone()
my_env.InjectThirdParty(libraries=["magic"])
my_env.Library(
    target="some_lib",
    source=["some_lib.cpp"],
    LIBDEPS=['b'],
)

If the result of the InjectThirdParty call is to add to LIBDEPS, then this will actually not happen and the results can be very confusing.

Some mechanism should be found to either prevent this error from being possible, or to introduce a syntax or feature that allows "inline" modifications to the Environment to be accumulative, rather than overwriting.


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