The resmoke.ini file was added during the rollout of hygienic builds to deal with the fact that while we were transitioning between hygienic builds and legacy style builds, we needed resmoke to be able to look in different places for the binaries under test. Having the build system create the resmoke.ini file for resmoke to consume and understand the placement of the intended build, was, at the time, an OK workaround.

The result, however, has been long-term troublesome:

• The implementation within SCons bypasses normal SCons dependency tracking and is built unconditionally: https://github.com/10gen/mongo/blob/541e9288b76b9cf99040522f7c05a80c2dcbcf6c/SConstruct#L5346-L5361

• Efforts to improve this have either been too complex (https://github.com/10gen/mongo/pull/430) or don't work right (https://github.com/10gen/mongo/pull/1534).

• When Ninja is in play, there is an inherent impossibility of correctly updating this file with multiple Ninja files in play, due to the issues identified in SERVER-53952. No amount of SCons hacking is going to give us a resmoke.ini in the root of the tree that is under simultaneous control of multiple Ninja files and behaves correctly. As a result, engineers hand edit the file (see SERVER-59648).

• The presence of resmoke.ini breaks the encapsulation of hygienic builds, where all build outputs are to be entirely quarantined within a build directory. But the resmoke.ini file can't be brought into that environment, because that would undermine its one use.

Long term, this problem should be obviated by the self-testable installs effort, where each installation will have its own entry points which test the install. However, we aren't there yet.

We need to find a way to eliminate the need for resmoke.ini file entirely.

One simple way to do this may be for resmoke itself to gain some heuristics to identify the available builds. For instance, if we gave each build a well known file (or keyed from one of the existing ones, like the license file), then resmoke could start by running a find command from cwd. If it finds one matching installation directory, it assumes that that is the intended build to test. If it finds zero, it reports an error. If it finds more than one, it either prompts the user to select the build to test, or logs the identified builds and errors out with a message to re-run with the installDir flag set as appropriate, if the environment is not interactive.

Alternatively, we could just require that resmoke always be invoked with installDir.

I'm happy to investigate other options.