[Scons-users] How to turn off source scanner

Jason Kenny dragon512 at live.com
Thu Feb 7 15:54:18 EST 2019


That does not make sense to me... the clone has nothing to do with this.

I can just do a:

env["SCANNERS"]=[]
env.Command(...)

and that worked fine. My understanding of the builders is that it uses an override environment, basically a proxy environment.. I am wrong.. but I would have thought the SCANNERS var would have been found in the OverrideEnvironment instance the builder should be using.

Not a big deal.. it all works

________________________________
From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill Deegan <bill at baddogconsulting.com>
Sent: Thursday, February 7, 2019 2:04 PM
To: SCons users mailing list
Subject: Re: [Scons-users] How to turn off source scanner

Of course it doesn't work. Scanners are already hooked.
When you clone you're initializing with no scanners and thus no hooks.

On Wed, Feb 6, 2019 at 11:46 PM Jason Kenny <dragon512 at live.com<mailto:dragon512 at live.com>> wrote:

Hi Bill,



Changing the code to:



env2=env.Clone(SCANNERS=[])

env2.Command(..



seems to work.



However



env.Command(

    […],

    […],

    "autoreconf -if && ./configure\

     CC=${CC} CXX=${CXX}\

     ",

     SCANNERS=[]

)



Does not. I would have thought that the environment override would have worked here. It does not to my surprise



It does looks like adding a



env.Command(

    […],

    […],

    "autoreconf -if && ./configure\

     CC=${CC} CXX=${CXX}\

     ",

     source_scanner=Scanner(

                function = lambda *lst,**kw: [],

                )

)



Works.



Thanks … moving on to the next issue.



Jason





From: Scons-users <scons-users-bounces at scons.org<mailto:scons-users-bounces at scons.org>> On Behalf Of Bill Deegan
Sent: Wednesday, February 6, 2019 9:40 PM
To: SCons users mailing list <scons-users at scons.org<mailto:scons-users at scons.org>>
Subject: Re: [Scons-users] How to turn off source scanner



>From manpage:

SCANNERS

A list of the available implicit dependency scanners. New file scanners may be added by appending to this list, although the more flexible approach is to associate scanners with a specific Builder. See the sections "Builder Objects" and "Scanner Objects," below, for more information.

Create a new environment and empty this variable? Use that environment for your command?



Does that work?



On Wed, Feb 6, 2019 at 9:31 PM Jason Kenny <dragon512 at live.com<mailto:dragon512 at live.com>> wrote:



Looking how to turn off a scanner for a build command.



Simple reproducer..



Run:

Git clone https://github.com/libunwind/libunwind.git<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibunwind%2Flibunwind.git&data=02%7C01%7C%7C740470e16595406aa66108d68d377af1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636851666754748129&sdata=RbiVI62R7OkyQNpjaEvbyLCxCooSc32bSWKJ021LdXc%3D&reserved=0>



In the libunwind folder add a Sconstruct with this content



env = Environment()

env.Command(

    ["Makefile"],

    [

        "include/compiler.h",

        "include/dwarf-eh.h",

        "include/dwarf.h",

        "include/dwarf_i.h",

        "include/libunwind-aarch64.h",

        "include/libunwind-arm.h",

        "include/libunwind-common.h.in<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibunwind-common.h.in&data=02%7C01%7C%7C740470e16595406aa66108d68d377af1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636851666754758146&sdata=%2FWjHL587nLaf6q3kI7Y3S5RRGPjfPHtitc4cquU6PHk%3D&reserved=0>",

        "include/libunwind-coredump.h",

        "include/libunwind-dynamic.h",

        "include/libunwind.h.in<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibunwind.h.in&data=02%7C01%7C%7C740470e16595406aa66108d68d377af1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636851666754778156&sdata=uvYDkgwspTjAfZZS6x3pGBN5czOOmI2RAdBNKDfztus%3D&reserved=0>",

        "include/libunwind-hppa.h",

        "include/libunwind-ia64.h",

        "include/libunwind_i.h",

        "include/libunwind-mips.h",

        "include/libunwind-ppc32.h",

        "include/libunwind-ppc64.h",

        "include/libunwind-ptrace.h",

        "include/libunwind-sh.h",

        "include/libunwind-tilegx.h",

        "include/libunwind-x86_64.h",

        "include/libunwind-x86.h",

        "include/mempool.h",

        "include/remote.h",

        "include/unwind.h",

    ],

    "autoreconf -if && ./configure\

     CC=${CC} CXX=${CXX}\

     "

)



Then run

Scons



Then run

Scons –debug=explain -n



You should see something as:

…

scons: Building targets ...

scons: rebuilding `Makefile' because:

           `include/config.h' is a new dependency

           `include/libunwind.h' is a new dependency

           `include/libunwind-common.h' is a new dependency

           `include/tdep/libunwind_i.h' is a new dependency

autoreconf -if && ./configure CC=gcc CXX=g++

scons: done building targets.



The reason for this is that the Commands source is a list of header files. These header files have a scanner running on them. When the configure logic is finished the config.h and other headers are generated. This cause a false rebuild to happen.



I would like to prevent the false rebuild.

The more complex case based on a function I am trying to define to make it easy to call autoconf project from scons to build a larger mega project. The issue I am having is that in case as this libunwind would be a “leaf component” that is needed by many other components. This rebuild of the Makefile causes a chain of build action that make for annoying and long builds on the second pass that are not needed. Technically the Makefile does not need to be rebuilt because config.h was added. However I have not found a way to get this fixed.



I tired adding



env.Ignore(['Makefile'],

    [

        'include/config.h',

           'include/libunwind.h',

           'include/libunwind-common.h',

           'include/tdep/libunwind_i.h',

    ]

)



But this results in a message of:

scons: rebuilding `Makefile' because the dependency order changed:…



Do you have thoughts on how to fix this? My main thought is to turn off the c\c++ scanner for this builder. However I am unaware of a method to do this.



Jason

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C740470e16595406aa66108d68d377af1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636851666754788161&sdata=ZhSd%2BmgxcABkD7xDRpODfAdG5O92YHYvrchDcs4B9vA%3D&reserved=0>

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C740470e16595406aa66108d68d377af1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636851666754798172&sdata=ckXxJfF9J8ig5Wg9URuWpCRwxViLlCmE3eR4BeLQVsY%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190207/a146c7a0/attachment-0001.html>


More information about the Scons-users mailing list