[Scons-users] scons checking targets actually built?

robert zeigler robert.zeigler at gmail.com
Thu Apr 18 21:17:07 EDT 2013


Hi WIlliam,

I confess that I was expecting it to. You're right about make showing
similar behavior for similar logic. But scons does so much additional work
to ensure the validity of the build that it caught me off guard. I suppose
it's less expecting scons to check that targets were built and more about
scons double-checking that the sources exist for downstream targets.

The actual situation I had was a case of operator error combined with
overly tolerant downstream programs. The operator error was (effectively)
me placing a $TARGET in the wrong place in a complex command; that resulted
in the command running successfully (output produced) but the output being
written to the wrong filename. So the target file didn't exist. However,
the next several steps in the build are (overly) fault tolerant with
respect to missing/empty inputs. Some of that I have control over, some of
it I don't. The end result was a build command failing at least two steps
downstream of where the real error occurred. Having scons detect that a
source which is theoretically supposed to be exist, based on a chain of
commands, but which was not actually built would be nice... but that
assumes all targets and sources are real. And as another poster pointed
out, fake targets are common and useful, so I suppose I'll live with the
current behavior for now, or else wrap the commands in, eg, a builder that
verifies its targets are built when I know that those targets are physical
files.

Cheers,

Robert




On Thu, Apr 18, 2013 at 7:50 PM, William Deegan
<bill at baddogconsulting.com>wrote:


> Robert,

>

> On Apr 18, 2013, at 4:13 PM, robert zeigler <robert.zeigler at gmail.com>

> wrote:

>

> > Hi,

> >

> > Fairly new to scons. I have been playing with it the last few days and

> like what I see. However, I stumbled on behavior today that has me troubled.

> >

> > Consider a very simple build script:

> >

> > Command(['a.txt'],[],"echo hi > $TARGET")

> > Command(['b.txt'],['a.txt'],"cat $SOURCE > $TARGET && echo foo >>

> $TARGET")

> >

> > This runs fine:

> >

> > scons: Reading SConscript files ...

> > scons: done reading SConscript files.

> > scons: Building targets ...

> > echo hi > a.txt

> > cat a.txt > b.txt && echo foo >> b.txt

> > scons: done building targets.

> >

> > Now consider an alternative command for building a:

> >

> > Command(['a.txt'],[],"echo hi > $TARGET && rm $TARGET")

> >

> > Then you get:

> >

> > scons: Reading SConscript files ...

> > scons: done reading SConscript files.

> > scons: Building targets ...

> > echo hi > a.txt && rm a.txt

> > cat a.txt > b.txt && echo humbug >> b.txt

> > cat: a.txt: No such file or directory

> > scons: *** [b.txt] Error 1

> > scons: building terminated because of errors.

> >

> > The build fails, of course, but what troubles me is that it doesn't fail

> until we attempt to build b.txt. I would have expected scons to verify that

> the target was actually build by the command; failing that, I'm surprised

> that it attempted to build b.txt when a.txt was clearly not present for

> b.txt to be built?

> >

> > Clarification on this is greatly appreciated. Although the case above is

> trivial, I ran into this issue in a non-trivial case, as well.

>

> So you've told SCons that the target is a.txt, it runs that command.

> At that point it expects a.txt to exist, because you told it that it would

> create it.

> Then you run the next command which depend on a.txt, and the shelled

> command fails.

>

> So to SCons it clearly was there at that point.

> You'll notice the same behavior with Make if you have a similar set of

> logic.

>

> Are you expecting it to rescan after a command is run which should create

> a file to check if it was created?

>

> -Bill

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20130418/d139645c/attachment.html>


More information about the Scons-users mailing list