Re: Code not rebuilt when switching between two VisualStudio versions

Is there a way by running the coverage version of cl.exe to find out the
path of the real CL.exe?

On Fri, Mar 26, 2021 at 7:54 AM Mats Wichmann <[email protected]> wrote:

> On 3/26/21 1:52 AM, Steve Hill (Wireless) via Scons-users wrote:
> > 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(
>
> One of the decision points as to whether to rebuild is whether the
> string which will be issued as the command to build a file (the
> builder's "action") has changed. The string is hashed, and that is
> compared with the action signature stored away from earlier builds.  The
> problem you're having here is that the action doesn't contain the actual
> compiler name/path, so SCons sees no difference.
>
> There is  a way to add things to be considered as part of an action
> signature - namely you can include construction variables, whose values
> will be slurped up and included. It looks something like this (from the
> manpage):
>
> a = Action(build_it, varlist=['XXX'])
>
> The problem is you're not writing your own actions, you want this to
> happen for pre-defined actions attached to the SCons-provided builders
> you're using (I assume you're using the standard ones like Program,
> Object, etc.).  Changing an existing action is tricky.
>
> You can read a bit more here:
>
> https://scons.org/doc/production/HTML/scons-man.html#action_objects
>
> Maybe someone else knows another route?
>
> (I'm going to look at eventually adding something on this somewhere,
> either docs or scons-recipes, you're right that the concept of  a tool
> masquerading as another tool is relatively common - on Linux/UNIX ccache
> is one of those. This means SCons doesn't see the actual one, and might
> not detect changes).
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users