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

Tue Apr 6 17:49:54 EDT 2021

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 <
scons-users at scons.org> 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 <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> 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
> 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
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20210406/050cff8e/attachment.htm>