[Scons-users] Code not rebuilt when switching between two VisualStudio versions

[Steve Hill (Wireless)]

Hi Mats,

Thanks for your reply.

>> It should be - you should be able to see the compiler as a dependency if you run scons with --tree=prune option, and you can later dump the database to see stored signatures with the sconsign command.

Obviously, I should have done this before posting! ... and it shows me the problem. We use a coverage tool that provides a replacement cl.exe/link.exe, which will then invoke the appropriate MSVC cl.exe/link.exe. This has the effect of obscuring the dependency on the real compiler - SCons only sees the coverage cl.exe as being the dependency. Could I use Depends() to indicate that the coverage cl.exe "depends on" the real MSVC cl.exe?

Thanks again,

Steve.

-----Original Message-----
From: Scons-users <scons-users-bounces at scons.org> On Behalf Of Mats Wichmann
Sent: 25 March 2021 15:43
To: scons-users at scons.org
Subject: Re: [Scons-users] Code not rebuilt when switching between two VisualStudio versions

On 3/25/21 1:54 AM, Steve Hill (Wireless) via Scons-users wrote:
> Hi all,
>
> We are using SCons 3.1.2 and are evaluating moving from MSVS 2017 to 
> MSVS 2019. We have provided a mechanism to switch the setting of 
> MSVS_VERSION/MSVC_VERSION from 14.1 to 14.2 when the Environment is 
> created, and this works well when building clean or incrementally with 
> the same toolchain. However, if switching between toolchains, the 
> C/C++ files don't get rebuilt and, as soon as one file is changed and 
> rebuilt so that the linker is invoked, we get a linker failure. It is 
> almost like the compiler is not included as a dependency of the object file?

It should be - you should be able to see the compiler as a dependency if you run scons with --tree=prune option, and you can later dump the database to see stored signatures with the sconsign command.

> Can anyone give me a clue as to how to ensure that the files are 
> correctly rebuilt (ideally without having to change the places where 
> the files are added into SCons, as our codebase is quite large.)

The thing to check would be if the toolchain is actually switching...
there's been several iterations of fixing up selecting the right one when there are multiple chains installed, some of those may have come after 3.1.2.  Memory is hazy as to the timeline...