...
It seems that the fix for SERVER-55165 may in fact be causing spurious rebuilds for pure SCons builds. I suspect that the add_to_implicit is causing the dependency list to oscillate build to build.
xgen-internal-githook commented on Mon, 21 Mar 2022 19:19:58 +0000: Author: {'name': 'Daniel Moody', 'email': 'daniel.moody@mongodb.com', 'username': 'dmoody256'} Message: SERVER-60426 stop inteldecimal script from setting dependencies in generator. Branch: master https://github.com/mongodb/mongo/commit/473b7ffe273c3cfde4e8ef5b4fda73d6742a6e5d JIRAUSER1253549 commented on Tue, 15 Mar 2022 19:05:53 +0000: acm yeah if I can repro it, I should be able to discover the details of exactly whats happening and form a better solution. Thanks! acm commented on Tue, 15 Mar 2022 18:56:07 +0000: daniel.moody - This reproduces for me every time on macOS with the following SCons invocation: $ python buildscripts/scons.py --variables-files=etc/scons/xcode_macosx.vars --variables-files=etc/scons/developer_versions.vars --dbg=on --opt=on --link-model=dynamic --implicit-cache --cache --build-fast-and-loose --visibility-support=on --install-action=hardlink --cxx-std=20 --experimental-optimization=\* --experimental-runtime-hardening=\* --debug=time '$DESTDIR/lib/libbase.dylib' After every run, I see it pulling state from cache: Retrieved `build/cached/third_party/IntelRDFPMathLib20U1/libintel_decimal128.dylib' from cache Retrieved `build/cached/third_party/IntelRDFPMathLib20U1/libintel_decimal128.tbd' from cache Retrieved `build/cached/third_party/IntelRDFPMathLib20U1/libintel_decimal128.tbd.no_uuid' from cache Command execution time: build/cached/third_party/IntelRDFPMathLib20U1/libintel_decimal128.tbd.no_uuid: 0.400576 seconds Now, there is a lot going on in that build, so I validated that I can see the same thing on linux with a simpler build: $ python3 buildscripts/scons.py --variables-files= --variables-files=etc/scons/mongodbtoolchain_stable_gcc.vars --variables-files=etc/scons/developer_versions.vars --dbg=on --opt=on --link-model=dynamic '$DESTDIR/lib/libbase.so' ICECC=icecc -j300 --implicit-cache Again, on re-running that command a second time, I see the intel library get rebuilt: scons: done reading SConscript files. scons: Building targets ... Linking build/optdebug/third_party/IntelRDFPMathLib20U1/libintel_decimal128.so scons: `build/install/lib/libbase.so' is up to date. scons: done building targets. But, and here is a critical insight: if I drop the --implicit-cache flag, this issue goes away: $ python3 buildscripts/scons.py --variables-files= --variables-files=etc/scons/mongodbtoolchain_stable_gcc.vars --variables-files=etc/scons/developer_versions.vars --dbg=on --opt=on --link-model=dynamic '$DESTDIR/lib/libbase.so' ICECC=icecc -j300 --implicit-cache ... scons: done reading SConscript files. scons: Building targets ... Linking build/optdebug/third_party/IntelRDFPMathLib20U1/libintel_decimal128.so scons: `build/install/lib/libbase.so' is up to date. scons: done building targets. Meanwhile, if I take out the call to add_to_implicit in src/third_party/IntelRDFPMathLib20U1/SConscript, the issue goes away (after one more spurious rebuild, with subsequent builds always up to date), even if I use --implicit-cache. I didn't realize that --implicit-cache was necessary to see this issue when I filed it. I almost always use that flag since it does significantly speed up pure SCons builds. Maybe the interaction between --implicit-cache and the call to add_to_implicit as a necessary setup for observing these rebuilds is enough to point to a root cause. Do you want to take the ticket back to pursue that angle?