[Scons-users] clarification on Depends()
Marc Branchaud
marcnarc at xiplink.com
Wed Jun 6 10:04:47 EDT 2018
On 2018-06-05 09:18 PM, Jason Kenny wrote:
> Bill ,
>
> I don’t mean to offend with the “generally pointless”. ( I realized that
> I might have been a little harsh with that statement.. sorry)
>
> What I have found is that when Scons prints this:
>
> +-hello
>
> | +-hello.o
>
> | | +-hello.c
>
> | | | +-fake.txt
>
> | | +-/usr/bin/gcc
>
> | +-/usr/bin/gcc
>
> You would think that a change to fake.txt would go up the change and
> cause to stuff to rebuild.
Well, not really, because hello.c doesn't *actually* change if fake.txt
changes.
Even if you had a fake builder that "created" hello.c whenever fake.txt
changed, if it's the same hello.c that was input to the Program builder
then the hello program (and hello.o) don't get rebuilt.
Even your toy Makefile
> Fake.txt:
>
> Hello.c:fake.txt
>
> Hello.o:hello.c
> cc hello.c
won't rebuild anything if fake.txt changes (Gnu make 4.1).
> However this is only true if
>
> | | +-hello.c
> | | | +-fake.txt
>
> Happens because of a builder. If it is a Depends() like it is here.
> Nothing happens. User is confused.
>
> If this looks like:
>
> +-hello
> | +-hello.o
> | | +-hello.c
> | | +-fake.txt
> | | +-/usr/bin/gcc
> | +-/usr/bin/gcc
>
> The hello.o will rebuild. If hello.c was used in more than one builder
> as a sources I would have to Depends() each target that hello.c might be
> part of.
>
> I understand the example here is a .c file. But don’t get hung up on
> that. This is a general builder(target,source) issue. Fake.txt here
> could have been #included via some funny macro expansion that SCons
> scanners cannot deal with correctly ( as is common with boost as an example)
Ah, I see where you're coming from now.
In the boost example, SCons lacks the means to apply your dependency.
As you say, the built-in scanner can't detect that fake.txt is an
implicit dependency. But a simple Depends("hello.c","fake.txt") doesn't
work because a change to fake.txt doesn't change hello.c itself, it
changes the preprocessor-expanded version of hello.c. SCons doesn't
have a concept of preprocessor-expanded files, so it can't express the
dependency you're looking for.
One solution is to teach new tricks to the built-in C scanner. I seem
to recall a recent thread here discussing the possibility of making the
scanner use the output of "cc -E".
Another option is to express the dependency yourself by making the C
preprocessor an explicit part of your build. Write a builder that runs
"cc -E" on .c files to create .expanded.c files, then pass that
builder's result to Program(). The built-in scanner should then detect
the implicit #include dependency on fake.txt.
M.
> Bill. I am confused as based on what you stated it seems my first
> example of:
>
> Depends(["hello.c")],["fake.txt"])
>
> Program("hello","hello.c")
>
> Should have rebuilt hello.o as hello.c should have been seen as out of
> data. What did I miss here?
>
> Jason
>
> *From:* Bill Deegan <bill at baddogconsulting.com>
> *Sent:* Tuesday, June 5, 2018 7:56 PM
> *To:* Jason Kenny <dragon512 at live.com>
> *Cc:* SCons users mailing list <scons-users at scons.org>
> *Subject:* Re: [Scons-users] clarification on Depends()
>
> Jason,
>
> I've been spending a lot of time in the decider/taskmaster logic lately.
>
> Depends do actually matter and are not "generally pointless"
>
> They're added to Node's bdepend list and depend_set which combined with
> sources and implicit dependencies are what is used to determine if the
> sources are out of date with respect to the target.
>
> -Bill
>
> On Tue, Jun 5, 2018 at 5:47 PM, Jason Kenny <dragon512 at live.com
> <mailto:dragon512 at live.com>> wrote:
>
> I think of this more as a make rule.
>
> I want to say for whatever reason that if the fake.txt is out of
> date that mean hello.c is out of date.
>
> So something like:
>
> Fake.txt:
>
> Hello.c:fake.txt
>
> Hello.o:hello.c
>
> cc hello.c
>
> Here in make land a change to fake.txt will spawn all rules that
> have fake.txt as a source.
>
> From what I understand the Depend() is generally pointless as the
> execution logic only cares about implicit depends of the source via
> the scanner, and if the source has a builder. If it has a builder
> then we care about depends of the source node, as now it is
> technically a target in the other builder. I can get different
> behavior via one of three ways.
>
> 1. Make an empty do nothing builder to make a depends() as a source
> of the of the node
> 2. Change/add a different decider to say this node is up-to-date if
> and only if it and any depends are all up-to-date. Currently
> this only returns True if this node in question is up-to-date,
> not if anything it depends on is as well.
> 3. Change the executor to care about depends of a source even if it
> does not have a builder
>
> Honestly there are special cases in which this is useful. Most of
> the time the scanner is the way to go.
>
> Jason
>
> *From:* Bill Deegan <bill at baddogconsulting.com
> <mailto:bill at baddogconsulting.com>>
> *Sent:* Tuesday, June 5, 2018 7:25 PM
> *To:* SCons users mailing list <scons-users at scons.org
> <mailto:scons-users at scons.org>>
> *Cc:* Jason Kenny <dragon512 at live.com <mailto:dragon512 at live.com>>
> *Subject:* Re: [Scons-users] clarification on Depends()
>
> On Tue, Jun 5, 2018 at 3:27 PM, Marc Branchaud <marcnarc at xiplink.com
> <mailto:marcnarc at xiplink.com>> wrote:
>
> On 2018-06-05 12:05 AM, Jason Kenny wrote:
>
> HI,
>
> I just want to clarify behavior of Depends() in SCons.
>
> I have a small sample:
>
> Depends(["hello.c")],["fake.txt"])
>
> Program("hello","hello.c")
>
> If I run this sample “hello” will build. If I change
> fake.txt, nothing will rebuild.
>
>
> Right. This is because you have nothing that builds hello.c, so
> SCons doesn't care that hello.c depends on anything.
>
> But SCons does know how to build hello.o. That knowledge is
> implicit in the Program builder. So SCons respects
> Depends("hello.o", "fake.txt")
>
> Put another way, SCons only performs actions to build hello.o
> (and, ultimately, hello), so it only cares about dependencies
> for the actions it undertakes.
>
> You could also use the target returned by the Program builder:
> hello_target = Program("hello", "hello.c")
> Depends(hello_target, "fake.txt")
> This achieves the same thing, and lets you avoid knowing the
> Program builder's intermediate artifacts.
>
> It would rebuild hello, but not necessarily rebuild hello.o
>
> So not exactly the same thing.
>
> -Bill
>
>
> M.
>
> I have a tree like this:
>
> +-hello
>
> | +-hello.o
>
> | | +-hello.c
>
> | | +-fake.txt
>
> | | +-/usr/bin/gcc
>
> | +-/usr/bin/gcc
>
> If I change the sample to this ( depends() is not hello.o vs
> hello.c)
>
> Depends(["hello.c")],["fake.txt"])
>
> Program("hello","hello.c")
>
> Now when I change fake.txt hello.o will rebuild. The tree
> here looks like:
>
> +-hello
>
> | +-hello.o
>
> | | +-hello.c
>
> | | +-fake.txt
>
> | | +-/usr/bin/gcc
>
> | +-/usr/bin/gcc
>
> Is this right… I have to know the target of a builder to
> use? I cannot use the source of a builder?
>
> 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Ca25e1c3b08b94567e3c808d5cb43e88c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636638414874226947&sdata=9xTM%2Fogjcekowt8cySadqFPfrk7mKGWBLzEwON2hL0U%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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7Ca25e1c3b08b94567e3c808d5cb43e88c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636638414874226947&sdata=9xTM%2Fogjcekowt8cySadqFPfrk7mKGWBLzEwON2hL0U%3D&reserved=0>
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
More information about the Scons-users
mailing list