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

[Steve Hill (Wireless)]

Hi Bill,

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

Sorry for the delay in replying. I’ve now had a chance to have a play and, as far as I can tell, the coverage cl.exe just passes the command-line arguments on to the underlying cl.exe. If there isn’t one available, I get:

$ ./cl
Exception: compiler not found cl.exe

And I get the same regardless of the arguments that are added to the command line…

Anyway, I could figure out the real cl.exe (by removing the coverage bin directory from the path and using shutil.which()) but I’m not sure how to then make this a default dependency without explicitly adding it to every object file, which would be quite unpleasant.

Thanks,

S.

From: Scons-users <scons-users-bounces at scons.org> On Behalf Of Bill Deegan
Sent: 26 March 2021 17:57
To: SCons users mailing list <scons-users at scons.org>
Subject: Re: [Scons-users] 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 <mats at wichmann.us<mailto:mats at wichmann.us>> 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<https://urldefense.com/v3/__https:/scons.org/doc/production/HTML/scons-man.html*action_objects__;Iw!!Niha4SQ!qR9jdHlKZb4Q12-1IWkJkaq7WqSre3SA9Usoz8hb3Xr7kZ-Nkq-qaqReYIn3r8L4rq65oc3a$>

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
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!qR9jdHlKZb4Q12-1IWkJkaq7WqSre3SA9Usoz8hb3Xr7kZ-Nkq-qaqReYIn3r8L4ru8AVJjU$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20210406/56f2424e/attachment-0001.htm>