Re: Code not rebuilt when switching between two VisualStudio versions

Hi Bill,

Thanks for this guidance. I’ve put something like this in place and it seems to have the desired effect.

I do wonder whether providing some official mechanism for doing this would be worthwhile (like adding the core compiler as a dependency of the coverage compiler, which can already be done but doesn’t – currently – work)? We have a few tools that have a compiler which ends up calling the MSVC compiler, e.g. Dynamic Analysis tools. I’m not against patching SCons (we already have a couple of other patches) but this does seem to be a fairly standard pattern, in the Windows world, at least. The patch that I put in place is generic, so we can use it for all tools that need to add this dependency, but it does feel like a use-case that SCons should be able to support without patching?

Anyway, my problem is resolved so thanks once again!

S.

From: Bill Deegan
Sent: 06 April 2021 22:50
To: SCons users mailing list <[email protected]>
Cc: Steve Hill (Wireless)
Subject: Re: [Scons-users] Code not rebuilt when switching between two VisualStudio versions

Steve,

O.k.
So the way SCons typically adds the compiler as an implicit dependency works by checking the first item on the command line and then checking in env['ENV']['PATH'] to find the first one.

The function which does that is in SCons/Action.py
CommandAction's method get_implicit_deps().

You might be able to "monkey patch" that function to always add the second path in PATH where it finds cl.exe as well.

import SCons.Action
old_get_implicit_deps = SCons.Action.CommandAction.get_implicit_deps
def my_get_implicit_deps(self, target, source, env, executor=None):
     ret_list = old_get_implicit_deps(self, target, source,env, executor)
     if PATH_TO_FAKE_CL in ret_list:
         ret_list.append(PATH_TO_REAL_CL)
    return ret_list

SCons.Action.CommandAction.get_implicit_deps = my_get_implicit_deps

Or something like that.

A bit of a hack, but then this is a hacky situation...

-Bill

On Tue, Apr 6, 2021 at 6:57 AM Steve Hill (Wireless) via Scons-users <[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>> On Behalf Of Bill Deegan
Sent: 26 March 2021 17:57
To: SCons users mailing list <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[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<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
[email protected]<mailto:[email protected]>
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$>
_______________________________________________
Scons-users mailing list
[email protected]<mailto:[email protected]>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://urldefense.com/v3/__https:/pairlist4.pair.net/mailman/listinfo/scons-users__;!!Niha4SQ!tnrUVzUNvgvY_UnajnO9Y21xMpMm0NoreufM-0h94hbZOvFqt78ZUi0IIDL4MDO8xlSCN0Oe$>

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