Login | Register
My pages Projects Community openCollabNet

Discussions > SCons Development (OBSOLETE) > [scons-dev] call for pre-testing next release: 0.95.1 available

Project highlights:

14 Nov 2017: Release 3.0.1 is now available at the download page.

18 Sep 2017: Release 3.0.0 is now available at the download page.

03 Nov 2016: Release 2.5.1 is now available at the download page.

scons
Discussion topic

Hide all messages in topic

All messages in topic

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Werner Schiendl <ws-news at gmx dot at>
Full name Werner Schiendl <ws-news at gmx dot at>
Date 2004-07-13 09:51:03 PDT
Message Hi,


I noticed that the "scons.bat" file is not installed any more in the process
of the setup (I remember earlier versions did so).

My configuration:

Windows XP
Python 2.3.4 (official binary installer)
NO prior version of SCons installed (fresh install of Python few days ago)

Invoked SCons' setup as following:

setup.py install --standard-lib


The setup runs to completion, last few lines of output:

[...]
running install_scripts
copying build\scripts\scons -> D:\DEVELO~1\Python23\Scripts
copying build\scripts\sconsign -> D:\DEVELO~1\Python23\Scripts
Installed SCons library modules into D:\DEVELO~1\Python​23\Lib\site-packag​es\
Installed SCons script into D:\DEVELO~1\Python23\Scripts


The "Scripts" directory has the "scons" file, but there is no "scons.bat" or
anything else that could be invoked on a Windows box.

Is this intentional? Probably not...


best regards

Werner


> I am working on preparing SCons version 0.96 for release. I'm asking
> for your help in testing out a pre-release 0.95.1 version, so that we
> can shake out more problems before the official release.
>
> WHY I'M ASKING FOR HELP WITH PRE-RELEASE TESTING:
>
> The next version of SCons will contain some significant refactorings of
> some key subsystems:
>
> -- The .sconsign file format has been changed to save additional
> information about the built targets. This additional
> information is used to support a new --debug=explain option
> that will tell you *why* a particular target is being rebuilt.
> A new SetOption('save_explain_info') (or --save-explain-info)
> option tells SCons to speed up the build by not saving this info.
>
> -- SCons now ships a "dblite.py" module (thanks to Ralf W.
> Grosse-Kunstleve) that is used as the new default DB format for
> .sconsign files specified using the the SConsignFile() function.
> We did this because different versions of Python have problems
> with the anydbm module that was the old default. If you want
> the old behavior, you should explicitly specify anydbm as follows:
>
> import anydbm
> SConsignFile(dbm_module=anydbm)
>
> -- The default Scanners are now associated with specific default
> builders, not with specific file suffixes. This eliminates
> inappropriate re-installs of .h files when a subsidiary .h
> file changes.
>
> -- The check for whether a file is up-to-date has been refactored
> to occur at a different point in SCons' analysis. This fixes
> some spurious circular dependencies involving generated .h files.
>
> These changes could have introduced unintended side effects that might,
> conceivably, have fallen through cracks in our regression test coverage.
> I'd like your help in finding any cases like that by running this
> pre-release version through your real-life builds.
>
> HOW TO HELP:
>
> Download one of the following packages and install SCons as you would
> normally:
>
> http://www.scons.org​/scons-0.95.1.tar.gz​
> http://www.scons.org​/scons-0.95.1.zip
> http://www.scons.org​/scons-local-0.95.1.​tar.gz
> http://www.scons.org​/scons-local-0.95.1.​zip
> http://www.scons.org​/scons-src-0.95.1.ta​r.gz
> http://www.scons.org​/scons-src-0.95.1.zi​p
>
> Please let me know if you notice any problems that seem to have been
> introduced by this version (and not open problems in 0.95 that are
> still unfixed). I'm especially interested in the following:
>
> -- If the performance of 0.95.1 seems to be noticeably slower
> than the performance of 0.95. The performance hit from the
> --debug=explain support should have been offset by speedups in
> other areas, but I'd like to know if your mileage varies.
>
> -- If 0.95.1 causes an up-to-date tree already built with 0.95 to
> rebuild anything. The new .sconsign file code should know how
> to read the old .sconsign file format and Do the Right Thing.
> The only case where rebuilds *should* occur is if you're using the
> SConsignFile() function and do not explicitly set the dbm_module
> to the same value as you used for 0.95 (anydbm by default).
>
> If you test out 0.95.1 and don't notice any problems, I'd like to know
> that, too--just so I can keep track.
>
> Thank you, and let me know if you have any questions.
>
> --SK
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
> For additional commands, e-mail: dev-help at scons dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author "Erling D dot Andersen" <e dot d dot andersen at mosek dot com>
Full name "Erling D dot Andersen" <e dot d dot andersen at mosek dot com>
Date 2004-07-06 03:34:13 PDT
Message ********************​********************​********************​****************
Denne mail er blevet scannet af http://www.virus112.com
********************​********************​********************​****************


Hi

I have test the new 0.95.1. On

Windows 32 bit
Suse Linux 9

it works nicely. It does not seem much slower
than the previous version.

In particular the new signature handling seems much more robust :-).
A bit advantage for me.

On Solaris I get problems see below. I have reported this problem
on Source Forge (885568). The problem is pkgchk is not on the PATH but
in

/usr/sbin

I think coming up with a fix so Scons works out the box is easy. So does not
it get fixed. [By the way I do not need sunc++. Wonder how can avoid this is setup.]

On MAC OSX Scons terminates normally but reports:

Exception exceptions.TypeError: <exceptions.TypeError instance at 0xd2f30> in ignored

I am not sure what is causing it. The previous version 0.95 did not do that. Are you interested
fixing this problem then we can dig out details?

Erling






Solaris problem:


scons: Reading SConscript files ...
sh: pkgchk: not found
IndexError: list index out of range:
  File "SConstruct", line 231:
    SetupPath()
  File "SConstruct", line 7:
    sys.path.append(os.p​ath.join(GetLaunchDi​r(),'construct', 'pysrc'))
  File "tools/scons/scons-l​ocal-0.95.1/SCons/Sc​ript/SConscript.py",​ line 578:
    proxy = get_DefaultEnvironmentProxy()
  File "tools/scons/scons-l​ocal-0.95.1/SCons/Sc​ript/SConscript.py",​ line 562:
    default_env = SCons.Defaults.Defau​ltEnvironment()
  File "tools/scons/scons-l​ocal-0.95.1/SCons/De​faults.py", line 67:
    _default_env = apply(SCons.Environm​ent.Environment, args, kw)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/En​vironment.py", line 264:
    apply_tools(self, tools, toolpath)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/En​vironment.py", line 120:
    env.Tool(tool, toolpath)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/En​vironment.py", line 893:
    return SCons.Tool.Tool(tool, map(self.subst, toolpath))(self)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/__init__.py", line 53:
    apply(self.generate, ( env, ) + args, kw)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/default.py", line 40:
    for t in SCons.Tool.tool_list​(env['PLATFORM'], env):
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/__init__.py", line 322:
    cxx_compiler = FindTool(cxx_compilers, env) or cxx_compilers[0]
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/__init__.py", line 232:
    if t.exists(env):
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/sunc++.py", line 48:
    path, cxx, shcxx, version = get_cppc(env)
  File "tools/scons/scons-l​ocal-0.95.1/SCons/To​ol/sunc++.py", line 29:
    cppcPath = os.path.dirname(line​.split()[-1])
Attachments

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Anthony Roach <aroach at electriceyeball dot com>
Full name Anthony Roach <aroach at electriceyeball dot com>
Date 2004-06-23 09:52:58 PDT
Message Steven Knight wrote:
> Can you strip it down to a test case? I just tried the first test case
> in test/option--implicit-cache.py, and the implicit dependencies in
> the .sconsign files seem to get written correctly after the first run.
> I confirmed this by adding a test.pass_test() call to explicitly stop the
> test while preserve the temporary directory, and running the "sconsign"
> script to dump the contents:

I haven't been able to reproduce this with a simple test case, and in fact the
build the orignally had the problem doesn't seem to have it anymore. I suspect
the problem was caused by some combination of switching from 0.95 to 0.95.1 and
turning on implicit-cache and perhaps some other unknown factors. I tried all
kinds of permutations of switching from 0.95 to 0.95.1 with and without
implicit-cache and with and without .sconsign files, and I just can't get the
problem to happen again. I could have even had some really old .sconsign file
laying around in some directory that I am not aware of or something, I just
don't know. Anyway, I don't think its worth spending any more time hunting this
one down.

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author stevenknight
Full name Steven Knight
Date 2004-06-22 20:03:02 PDT
Message Hi Anthony--

> > I am working on preparing SCons version 0.96 for release. I'm asking
> > for your help in testing out a pre-release 0.95.1 version, so that we
> > can shake out more problems before the official release.
>
> I found another problem. Using --implicit-cache in a pristine
> source tree with no .sconsign files causes scons to not scan for any
> dependencies and so there are no implicit dependenices at all. This
> is a pretty serious problem, and I'm kind of surprised that the
> implicit-cache test didn't catch it.

Can you strip it down to a test case? I just tried the first test case
in test/option--implicit-cache.py, and the implicit dependencies in
the .sconsign files seem to get written correctly after the first run.
I confirmed this by adding a test.pass_test() call to explicitly stop the
test while preserve the temporary directory, and running the "sconsign"
script to dump the contents:

    $ SCONS_LIB_DIR=`pwd`/​build/test-tar-gz/li​b/scons python build/test-tar-gz/bin/sconsign /var/tmp/testcmd.1/.sconsign
    prog: None 08c261a7933d47c49ac9​2711eba7726e None
            prog.o: c4d70a7c1971b4b0183e​2a40078ef1a5
    prog.o: None c4d70a7c1971b4b0183e​2a40078ef1a5 None
            subdir/prog.c: e1f98c33cd60679f04ea​cff21530b8eb
            include/foo.h: f1a277c946ab54bd50e7​b14b87d05654
            include/bar.h: 775fb945666ac76e6ad8​2b29637d9dd9
    $ SCONS_LIB_DIR=`pwd`/​build/test-tar-gz/li​b/scons python build/test-tar-gz/bin/sconsign /var/tmp/testcmd.1/s​ubdir/.sconsign
    prog: None 2ed630291f91cd527bfe​f35d17ec6eb1 None
            subdir/prog.o: 9a255b7150ecebb6d322​ee4641ad6004
    prog.o: None 9a255b7150ecebb6d322​ee4641ad6004 None
            subdir/prog.c: e1f98c33cd60679f04ea​cff21530b8eb
            subdir/include/foo.h: a136936c3433d19281b2​6ee66f62f460
            subdir/include/bar.h: fe3f73246132585210b2​47312f386913
    $ SCONS_LIB_DIR=`pwd`/​build/test-tar-gz/li​b/scons python build/test-tar-gz/bin/sconsign /var/tmp/testcmd.1/v​ariant/.sconsign
    prog: None 08c261a7933d47c49ac9​2711eba7726e None
            variant/prog.o: c4d70a7c1971b4b0183e​2a40078ef1a5
    prog.o: None c4d70a7c1971b4b0183e​2a40078ef1a5 None
            subdir/prog.c: e1f98c33cd60679f04ea​cff21530b8eb
            include/foo.h: f1a277c946ab54bd50e7​b14b87d05654
            include/bar.h: 775fb945666ac76e6ad8​2b29637d9dd9
    $

Perhaps there's an interaction with some other options you have enabled?

        --SK


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Anthony Roach <aroach at electriceyeball dot com>
Full name Anthony Roach <aroach at electriceyeball dot com>
Date 2004-06-22 09:13:42 PDT
Message Steven Knight wrote:
> I am working on preparing SCons version 0.96 for release. I'm asking
> for your help in testing out a pre-release 0.95.1 version, so that we
> can shake out more problems before the official release.

I found another problem. Using --implicit-cache in a pristine source tree with
no .sconsign files causes scons to not scan for any dependencies and so there
are no implicit dependenices at all. This is a pretty serious problem, and I'm
kind of surprised that the implicit-cache test didn't catch it.

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author broonie
Full name Mark Brown
Date 2004-06-21 04:40:19 PDT
Message On Sun, Jun 20, 2004 at 08:49:31PM -0500, Chad Austin wrote:

> FWIW, sometimes you should rebuild when the name or path of a source file
> changes. As I understand it (correct me if I'm wrong), Visual C++ links
> debug information in OBJ files to the absolute path of the source file so
> users of a debug library can step into its source, provided they built it.

Certainly, Unix tools will put the path to the source they were given
into the debug information (ie, if you build 'foo.c' they'll include
that and if you build '../../foo.c' or whatever they'll include that).

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Chad Austin <aegisk at vrac dot iastate dot edu>
Full name Chad Austin <aegisk at vrac dot iastate dot edu>
Date 2004-06-20 18:49:31 PDT
Message Charles Crain wrote:
>
>> The problem with the above is that the paths to the source and target
>> aren't there, and the .abspath modified on the source file isn't
>> expanded and is instead replaced by _abspath. Maybe this isn't a bug
>> either, but it surprised me.
>>
> I can at least explain this, since I wrote the code that does it. The
> basic problem is that we don't want the names or paths of source files
> to affect whether a target is rebuilt. We only care about the content
> of the source files, or rather the bsig of the target file, which is
 > generated by the content of the source files.

FWIW, sometimes you should rebuild when the name or path of a source file
changes. As I understand it (correct me if I'm wrong), Visual C++ links debug
information in OBJ files to the absolute path of the source file so users of a
debug library can step into its source, provided they built it.

Chad

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Chad Austin <aegisk at vrac dot iastate dot edu>
Full name Chad Austin <aegisk at vrac dot iastate dot edu>
Date 2004-06-18 23:41:04 PDT
Message All of my builds seem to work fine. Performance-wise, the difference between
save-explain-info=1 and 0 is negligible.

SConsignFile() works wonderfully. (Thanks Ralf!)

If I run into anything else before 0.96, I'll let you know.

Chad


Steven Knight wrote:

> I am working on preparing SCons version 0.96 for release. I'm asking
> for your help in testing out a pre-release 0.95.1 version, so that we
> can shake out more problems before the official release.
>
> WHY I'M ASKING FOR HELP WITH PRE-RELEASE TESTING:
>
> The next version of SCons will contain some significant refactorings of
> some key subsystems:
>
> -- The .sconsign file format has been changed to save additional
> information about the built targets. This additional
> information is used to support a new --debug=explain option
> that will tell you *why* a particular target is being rebuilt.
> A new SetOption('save_explain_info') (or --save-explain-info)
> option tells SCons to speed up the build by not saving this info.
>
> -- SCons now ships a "dblite.py" module (thanks to Ralf W.
> Grosse-Kunstleve) that is used as the new default DB format for
> .sconsign files specified using the the SConsignFile() function.
> We did this because different versions of Python have problems
> with the anydbm module that was the old default. If you want
> the old behavior, you should explicitly specify anydbm as follows:
>
> import anydbm
> SConsignFile(dbm_module=anydbm)
>
> -- The default Scanners are now associated with specific default
> builders, not with specific file suffixes. This eliminates
> inappropriate re-installs of .h files when a subsidiary .h
> file changes.
>
> -- The check for whether a file is up-to-date has been refactored
> to occur at a different point in SCons' analysis. This fixes
> some spurious circular dependencies involving generated .h files.
>
> These changes could have introduced unintended side effects that might,
> conceivably, have fallen through cracks in our regression test coverage.
> I'd like your help in finding any cases like that by running this
> pre-release version through your real-life builds.
>
> HOW TO HELP:
>
> Download one of the following packages and install SCons as you would
> normally:
>
> http://www.scons.org​/scons-0.95.1.tar.gz​
> http://www.scons.org​/scons-0.95.1.zip
> http://www.scons.org​/scons-local-0.95.1.​tar.gz
> http://www.scons.org​/scons-local-0.95.1.​zip
> http://www.scons.org​/scons-src-0.95.1.ta​r.gz
> http://www.scons.org​/scons-src-0.95.1.zi​p
>
> Please let me know if you notice any problems that seem to have been
> introduced by this version (and not open problems in 0.95 that are
> still unfixed). I'm especially interested in the following:
>
> -- If the performance of 0.95.1 seems to be noticeably slower
> than the performance of 0.95. The performance hit from the
> --debug=explain support should have been offset by speedups in
> other areas, but I'd like to know if your mileage varies.
>
> -- If 0.95.1 causes an up-to-date tree already built with 0.95 to
> rebuild anything. The new .sconsign file code should know how
> to read the old .sconsign file format and Do the Right Thing.
> The only case where rebuilds *should* occur is if you're using the
> SConsignFile() function and do not explicitly set the dbm_module
> to the same value as you used for 0.95 (anydbm by default).
>
> If you test out 0.95.1 and don't notice any problems, I'd like to know
> that, too--just so I can keep track.
>
> Thank you, and let me know if you have any questions.
>
> --SK
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
> For additional commands, e-mail: dev-help at scons dot tigris dot org

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Charles Crain <chux at houston dot rr dot com>
Full name Charles Crain <chux at houston dot rr dot com>
Date 2004-06-17 14:50:06 PDT
Message Anthony Roach wrote:

> Steven Knight wrote:
>
>> I am working on preparing SCons version 0.96 for release. I'm asking
>> for your help in testing out a pre-release 0.95.1 version, so that we
>> can shake out more problems before the official release.
>
>
> On Windows the linker command file stuffs seems to be running twice.
> For example:
>
>
> Using tempfile c:\docume~1\aroach​\locals~1\temp\tm​pxtuqb1.lnk for
> command line:
> link /nologo /NODEFAULTLIB /MACHINE:IX86 /DEBUG:FULL /DEBUGTYPE:CV ...
> link @c:\docume~1\aroac​h\locals~1\temp\t​mpxtuqb1.lnk
> del c:\docume~1\aroach​\locals~1\temp\tm​pxtuqb1.lnk
> Using tempfile c:\docume~1\aroach​\locals~1\temp\tm​pnz_cqp.lnk for
> command line:
> link /nologo /NODEFAULTLIB /MACHINE:IX86 /DEBUG:FULL /DEBUGTYPE:CV ...
> Creating library C:\penguin\built.n​et\debug\ni_tagger​_lv.lib and
> object C:\penguin\built.n​et\debug\ni_tagger​_lv.exp
>
> It doesn't say it is deleting the second tmp file, but I don't see any
> left over tmp files, so either it isn't actually generating the second
> one or the del statement isn't printed out.
>
>
Is it possible that it's only printing out the second time and not
actually doing anything? I also notice that not only is there no
mention of the file being deleted, but there's no mention of the second
link actually taking place, as in:
link @c:\docume~1\aroac​h\locals~1\temp\t​mpnz_cqp.lnk <-- that's the
actual command, which is shown for the first temp file but not the second.

-Charles



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Anthony Roach <aroach at electriceyeball dot com>
Full name Anthony Roach <aroach at electriceyeball dot com>
Date 2004-06-17 13:55:44 PDT
Message Steven Knight wrote:
> I am working on preparing SCons version 0.96 for release. I'm asking
> for your help in testing out a pre-release 0.95.1 version, so that we
> can shake out more problems before the official release.

On Windows the linker command file stuffs seems to be running twice. For example:


Using tempfile c:\docume~1\aroach​\locals~1\temp\tm​pxtuqb1.lnk for command line:
link /nologo /NODEFAULTLIB /MACHINE:IX86 /DEBUG:FULL /DEBUGTYPE:CV ...
link @c:\docume~1\aroac​h\locals~1\temp\t​mpxtuqb1.lnk
del c:\docume~1\aroach​\locals~1\temp\tm​pxtuqb1.lnk
Using tempfile c:\docume~1\aroach​\locals~1\temp\tm​pnz_cqp.lnk for command line:
link /nologo /NODEFAULTLIB /MACHINE:IX86 /DEBUG:FULL /DEBUGTYPE:CV ...
    Creating library C:\penguin\built.n​et\debug\ni_tagger​_lv.lib and object
C:\penguin\built.n​et\debug\ni_tagger​_lv.exp

It doesn't say it is deleting the second tmp file, but I don't see any left over
tmp files, so either it isn't actually generating the second one or the del
statement isn't printed out.


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Charles Crain <chux at houston dot rr dot com>
Full name Charles Crain <chux at houston dot rr dot com>
Date 2004-06-17 12:07:21 PDT
Message > The problem with the above is that the paths to the source and target
> aren't there, and the .abspath modified on the source file isn't
> expanded and is instead replaced by _abspath. Maybe this isn't a bug
> either, but it surprised me.
>
I can at least explain this, since I wrote the code that does it. The
basic problem is that we don't want the names or paths of source files
to affect whether a target is rebuilt. We only care about the content
of the source files, or rather the bsig of the target file, which is
generated by the content of the source files.

The way we used to do this was to generate a dummy list of sources and
targets that we used for signature calculation. I think that the
sources were always [ '__s1__', '__s2__' ] and the targets were always [
'__t1__', '__t2__' ]. Well, when we started adding cool stuff like
command generators and so forth that might make assumptions about the
name or number of source or target files in a build (like the DLL
emitter in Windows which will crap out if there is not a target with a
".dll" suffix), then these dummy sources/targets broke down.

Then I changed it to use the actual name of the source and target nodes
with path information stripped. The idea was that we might rebuild if
the name of the source file changed but the content did not, but that
this was a very small corner case, and it was still correct anyway. And
that was good until we added the cool stuff like .base and .abspath and
all that, because those did not produce Node objects but rather strings
that were NOT stripped from signature calculation. Abspath was a
particular problem because now the path of the source or target was all
of a sudden affecting rebuilds, which was not so much a corner case.

So now what we do is we canonicalize the path, by appending the
attribute name (abspath, base, basename, whatever) to the file name with
no path information. Which works great. Except that this was never
intended for human consumption. And now that we have the new --debug
option, humans are consuming it. So we might need to pretty it up a
little. Maybe changing it to someting more obtuse looking like <source
tag: abspath(AbsTime.cpp) > or something like that would work? The
other option is to add extra logic to print the real path names for the
--debug info only, but still use the canonicalized versions for
signature calculation.

-Charles



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author Anthony Roach <aroach at electriceyeball dot com>
Full name Anthony Roach <aroach at electriceyeball dot com>
Date 2004-06-17 07:11:05 PDT
Message Steven Knight wrote:
> I am working on preparing SCons version 0.96 for release. I'm asking
> for your help in testing out a pre-release 0.95.1 version, so that we
> can shake out more problems before the official release.

I just tried it on one of my builds and it seems to work fine. I use the old
style .sconsign files rather than the new database backed ones, so I can't
comment on that. I did notice that when I upgraded to 0.95.1 it didn't rebuild
everything (it did rebuild some things, which is odd) or spit out a bunch of
corrupt .sconsign warnings, which is good. My no-op build time with
--implicit-cache and --max-drift=1 went from 3s in 0.95 to 5s in 0.95.1. Using
--save-explain-info=0 didn't change the no-op build time at all. I've attached
profile runs for no-op builds with 0.95 and 0.95.1 with --save-explain-info=0. A
quick glance at the profile results didn't show any obvious problems, but it
does seem like some of the more expensive scons calls are being called more
often in 0.95.1 than in 0.95.

Hmm, it looks like the explain info isn't saved if the file isn't built. If I do
a build with --save-explain-info=0, then a no-op build without
--save-explain-info and then change a header file and do a build with
--debug=explain, scons says it can't explain why the .obj file is rebuilt
because there is no previous build information saved. I'm not sure if this is a
bug or expected behaviour, but it confused me at first.

Another odd thing about --debug=explain is that the command lines that are
printed aren't the real command lines that are used to build the file. I can
understand that the include path stuff isn't there, because it isn't used for
signature calculation, but the source and target parts are there but they aren't
the same as the real command line. For example:

scons: rebuilding `build.net\debug\n​i\dsc\AbsTime.obj'​ because the build action
changed:
                old: cl /nologo /c /GB /GF /GX /GR /W3 /FI ni/dsc/basics.h /Od /M
Dd /Z7 /DRELEASE=0 /c AbsTime.cpp_abspath /FoAbsTime.obj /Z7
                new: cl /nologo /c /GB /GF /GX /GR /W3 /Ze /FI ni/dsc/basics.h /O
d /MDd /Z7 /DRELEASE=0 /c AbsTime.cpp_abspath /FoAbsTime.obj /Z7

* Building C:\penguin\iak\sh​ared\trunk\build.n​et\debug\ni\dsc\​AbsTime.obj:
cl /nologo /c /GB /GF /GX /GR /W3 /Ze /FI ni/dsc/basics.h /Od /MDd /Z7 /DRELEASE
=0 /TP /IC:\penguin\iak\shared\trunk /IC:\penguin\iak\​shared\trunk\depen​ds\NI-PA
L\Includes "/IC:\Program Files\National Instruments\LabVIEW 7.1\cintools" /IC:\p
enguin\iak\shared​trunk\depends\icu​\win32\include /c C:\penguin\iak\shared\trunk
\ni\dsc\AbsTime.cpp /Fobuild.net\debug​ni\dsc\AbsTime.ob​j /Z7
AbsTime.cpp

The problem with the above is that the paths to the source and target aren't
there, and the .abspath modified on the source file isn't expanded and is
instead replaced by _abspath. Maybe this isn't a bug either, but it surprised me.

Besides the above "problems" the --debug=explain stuff works great. I especially
like the way it prints out the old and new command lines if it was the command
line that changed. Is there any performance hit for having it always turned on?
It doesn't seem to run any slower with it on, but I didn't actually time it. I'd
like to add command line diffing to --debug=explain using the Python diff
module... that'd be pretty sweet.

I'll test 0.95.1 on some of my larger builds later today and let you know how it
goes.
Attachments

Re: [scons-dev] call for pre-testing next release: 0.95.1 available

Author timot
Full name Timothee Besset
Date 2004-06-17 01:22:50 PDT
Message Working fine here. Both projects GtkRadiant and DOOM are using
SConsignFile() and rebuilt fine. No noticeable speed difference either.

radiant build spits out warnings like 'two different environments were
specified for target tools/quake3/common/vfs.o, but they appear to have
the same action'. That doesn't break anything though.

TTimo

Steven Knight wrote:

>I am working on preparing SCons version 0.96 for release. I'm asking
>for your help in testing out a pre-release 0.95.1 version, so that we
>can shake out more problems before the official release.
>
>WHY I'M ASKING FOR HELP WITH PRE-RELEASE TESTING:
>
>The next version of SCons will contain some significant refactorings of
>some key subsystems:
>
> -- The .sconsign file format has been changed to save additional
> information about the built targets. This additional
> information is used to support a new --debug=explain option
> that will tell you *why* a particular target is being rebuilt.
> A new SetOption('save_explain_info') (or --save-explain-info)
> option tells SCons to speed up the build by not saving this info.
>
> -- SCons now ships a "dblite.py" module (thanks to Ralf W.
> Grosse-Kunstleve) that is used as the new default DB format for
> .sconsign files specified using the the SConsignFile() function.
> We did this because different versions of Python have problems
> with the anydbm module that was the old default. If you want
> the old behavior, you should explicitly specify anydbm as follows:
>
> import anydbm
> SConsignFile(dbm_module=anydbm)
>
> -- The default Scanners are now associated with specific default
> builders, not with specific file suffixes. This eliminates
> inappropriate re-installs of .h files when a subsidiary .h
> file changes.
>
> -- The check for whether a file is up-to-date has been refactored
> to occur at a different point in SCons' analysis. This fixes
> some spurious circular dependencies involving generated .h files.
>
>These changes could have introduced unintended side effects that might,
>conceivably, have fallen through cracks in our regression test coverage.
>I'd like your help in finding any cases like that by running this
>pre-release version through your real-life builds.
>
>HOW TO HELP:
>
>Download one of the following packages and install SCons as you would
>normally:
>
> http://www.scons.org​/scons-0.95.1.tar.gz​
> http://www.scons.org​/scons-0.95.1.zip
> http://www.scons.org​/scons-local-0.95.1.​tar.gz
> http://www.scons.org​/scons-local-0.95.1.​zip
> http://www.scons.org​/scons-src-0.95.1.ta​r.gz
> http://www.scons.org​/scons-src-0.95.1.zi​p
>
>Please let me know if you notice any problems that seem to have been
>introduced by this version (and not open problems in 0.95 that are
>still unfixed). I'm especially interested in the following:
>
> -- If the performance of 0.95.1 seems to be noticeably slower
> than the performance of 0.95. The performance hit from the
> --debug=explain support should have been offset by speedups in
> other areas, but I'd like to know if your mileage varies.
>
> -- If 0.95.1 causes an up-to-date tree already built with 0.95 to
> rebuild anything. The new .sconsign file code should know how
> to read the old .sconsign file format and Do the Right Thing.
> The only case where rebuilds *should* occur is if you're using the
> SConsignFile() function and do not explicitly set the dbm_module
> to the same value as you used for 0.95 (anydbm by default).
>
>If you test out 0.95.1 and don't notice any problems, I'd like to know
>that, too--just so I can keep track.
>
>Thank you, and let me know if you have any questions.
>
> --SK
>
>
>----------------​--------------------​--------------------​-------------
>To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
>For additional commands, e-mail: dev-help at scons dot tigris dot org
>
>
>
>
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org

[scons-dev] call for pre-testing next release: 0.95.1 available

Author stevenknight
Full name Steven Knight
Date 2004-06-16 20:41:46 PDT
Message I am working on preparing SCons version 0.96 for release. I'm asking
for your help in testing out a pre-release 0.95.1 version, so that we
can shake out more problems before the official release.

WHY I'M ASKING FOR HELP WITH PRE-RELEASE TESTING:

The next version of SCons will contain some significant refactorings of
some key subsystems:

    -- The .sconsign file format has been changed to save additional
        information about the built targets. This additional
        information is used to support a new --debug=explain option
        that will tell you *why* a particular target is being rebuilt.
        A new SetOption('save_explain_info') (or --save-explain-info)
        option tells SCons to speed up the build by not saving this info.

    -- SCons now ships a "dblite.py" module (thanks to Ralf W.
        Grosse-Kunstleve) that is used as the new default DB format for
        .sconsign files specified using the the SConsignFile() function.
        We did this because different versions of Python have problems
        with the anydbm module that was the old default. If you want
        the old behavior, you should explicitly specify anydbm as follows:

                import anydbm
                SConsignFile(dbm_module=anydbm)

    -- The default Scanners are now associated with specific default
        builders, not with specific file suffixes. This eliminates
        inappropriate re-installs of .h files when a subsidiary .h
        file changes.

    -- The check for whether a file is up-to-date has been refactored
        to occur at a different point in SCons' analysis. This fixes
        some spurious circular dependencies involving generated .h files.

These changes could have introduced unintended side effects that might,
conceivably, have fallen through cracks in our regression test coverage.
I'd like your help in finding any cases like that by running this
pre-release version through your real-life builds.

HOW TO HELP:

Download one of the following packages and install SCons as you would
normally:

        http://www.scons.org​/scons-0.95.1.tar.gz​
        http://www.scons.org​/scons-0.95.1.zip
        http://www.scons.org​/scons-local-0.95.1.​tar.gz
        http://www.scons.org​/scons-local-0.95.1.​zip
        http://www.scons.org​/scons-src-0.95.1.ta​r.gz
        http://www.scons.org​/scons-src-0.95.1.zi​p

Please let me know if you notice any problems that seem to have been
introduced by this version (and not open problems in 0.95 that are
still unfixed). I'm especially interested in the following:

    -- If the performance of 0.95.1 seems to be noticeably slower
        than the performance of 0.95. The performance hit from the
        --debug=explain support should have been offset by speedups in
        other areas, but I'd like to know if your mileage varies.

    -- If 0.95.1 causes an up-to-date tree already built with 0.95 to
        rebuild anything. The new .sconsign file code should know how
        to read the old .sconsign file format and Do the Right Thing.
        The only case where rebuilds *should* occur is if you're using the
        SConsignFile() function and do not explicitly set the dbm_module
        to the same value as you used for 0.95 (anydbm by default).

If you test out 0.95.1 and don't notice any problems, I'd like to know
that, too--just so I can keep track.

Thank you, and let me know if you have any questions.

    --SK


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@scon​s.tigris.org
For additional commands, e-mail: dev-help at scons dot tigris dot org
Messages per page: