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

Steve Hill (Wireless) Steve.Hill1 at viavisolutions.com
Fri Mar 26 03:52:10 EDT 2021


Hi Bill,

The command line is unchanged. When you install the coverage tool, it results in vcvarsall.bat adding the path to the coverage ‘bin’ directory ahead of the one for MSVC:

PATH=C:\Program Files (x86)\BullseyeCoverage\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Tools\MSVC\14.15.26726\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\...

That means that the cl.exe and link.exe that are invoked are the coverage versions, which then do what they need to do before invoking the real compiler or linker (presumably using the directories in the PATH other than its own.) We have other tools (e.g. dynamic code analysis) that work in the same way – it seems quite standard, under Windows at least; this just happens to be the first tool where we have encountered it.

Since it supports multiple versions of MSVS, it may call the compiler for either MSVS 2017 or MSVS 2019 – but SCons has no way of knowing that. I figure that I need to somehow tell SCons that this extra dependency exists.

I’ve tried:

env.Depends(
    r"C:\Program Files (x86)\BullseyeCoverage\bin\cl.EXE",
    r"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Tools\MSVC\14.15.26726\bin\HostX64\x64\cl.exe"
)

And that shows up in the tree:

  |   | +-C:\Program Files (x86)\BullseyeCoverage\bin\cl.EXE
  |   |   +-C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Tools\MSVC\14.15.26726\bin\HostX64\x64\cl.exe

But the files don’t get rebuilt when I add the new dependency so I assume that, since the coverage compiler is not a target, the new dependency is not considered when deciding whether to rebuild the source file.

Any other ideas?

Thanks,

S.


From: Bill Deegan
Sent: 25 March 2021 18:40
To: SCons users mailing list <scons-users at scons.org>
Cc: Steve Hill (Wireless)
Subject: Re: [Scons-users] Code not rebuilt when switching between two VisualStudio versions

Steve,

Can you share an example command line with your coverage tool? is the cl.exe still on the command line?

-Bill

On Thu, Mar 25, 2021 at 10:06 AM Steve Hill (Wireless) via Scons-users <scons-users at scons.org<mailto:scons-users at scons.org>> wrote:
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<mailto:scons-users-bounces at scons.org>> On Behalf Of Mats Wichmann
Sent: 25 March 2021 15:43
To: scons-users at scons.org<mailto: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...

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://urldefense.com/v3/__https:/pairlist4.pair.net/mailman/listinfo/scons-users__;!!Niha4SQ!tQGkm0CbWwJZmteZp38xi6FgZ3zfqBQNxy0aF_roI2yit2OmfTMw1KbHU7YR6yuG0om9zpsM$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20210326/ac98d738/attachment-0001.html>


More information about the Scons-users mailing list