scons cannot reliably be stopped by ctr+C in configure contexts

[bdbaddog]

This issue was originally created at: 2008-07-31 06:46:59. This issue was reported by: cournape. cournape said at 2008-07-31 06:46:59

Hi,

When I use scons in configure contexts, and try to stop it with ctrl+C, scons becomes unreliable. It does not stop quickly, and worse, for the tests running at the time I send ctrl+C, the tests fail and are not re-run. For example:

env = Environment(tools=["gcc", "gnulink"])

# Just check a bunch of types, long enough list to have time to stop it
types = [
    "bool",
    "unsigned short",
    "short",
    "int",
    "unsigned int",
    "long",
    "unsigned long",
    "long long",
    "unsigned long long",
    "float",
    "double",
]

config = env.Configure()
for t in types:
    config.CheckTypeSize(t)
config.Finish()

For example, if I send ctrl+C at the beginning of the configuration:

scons: Reading SConscript files ...
Checking size of bool ... no
Checking size of unsigned short ... yes
Checking size of short ... no
Checking size of int ... no
Checking size of unsigned int ... no
Checking size of long ... no
Checking size of unsigned long ... yes
Checking size of long long ... no
Checking size of unsigned long long ... no
Checking size of float ... yes
Checking size of double ... no
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

And rerunning it gives me:

scons: Reading SConscript files ...
Checking size of bool ... (cached) no
Checking size of unsigned short ... (cached) yes
Checking size of short ... (cached) no
Checking size of int ... (cached) no
Checking size of unsigned int ... (cached) no
Checking size of long ... (cached) no
Checking size of unsigned long ... (cached) yes
Checking size of long long ... (cached) no
Checking size of unsigned long long ... (cached) no
Checking size of float ... (cached) yes
Checking size of double ... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

gregnoel said at 2008-08-05 08:35:40

Bug party triage. In general, stopping a run during configure is not a priority, but keeping SCons from caching an incorrect result is. (Fixing the latter may well fix the former, though.)

rhl said at 2008-12-03 12:46:41

(I could have sworn that I added this before; sorry if it's a duplicate)

Here are the details on how I've seen this bug bite. The only solution seems to be to rm -rf .scon*

It can happen that the files in .sconf_temp get out of sync with expectations (the .sconsign.dblite file?); this leads to configure failing. I think that this usually happens if you ^C out of a build, but am not sure. THe failures are things like:

scons: Configure: Checking for C++ library pex_logging...
scons: Configure: ".sconf_temp/conftest_31.cpp" is up to date.
scons: Configure: The original builder output was:
 |.sconf_temp/conftest_31.cpp <-
 |  |
 |  |
 |  |
 |  |int
 |  |main() {
 |  |
 |  |return 0;
 |  |}
 |  |
 |
g++ -o .sconf_temp/conftest_31.o -c -O0 2
g++ -o .sconf_temp/conftest_31 .sconf_temp/conftest_31.o
Undefined symbols:
 "_main", referenced from:
     start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
scons: Configure: no

If I look at .sconf_temp/conftest_31.cpp it does NOT look the way that scons expected, it clearly belongs to a different test:

#include <lsst/pex/logging/Trace.h>

The odd thing is that the number of .cpp files in .sconf_temp is different in the clean (successful) build and the one that was interrupted. Once this has happened scons is in trouble, as it expects e.g. conftest_12.cpp to contain main, but actually it's in conftest_13.cpp as we have an extra conftest_12.cpp that came from who-knows-where.

I can't see how this happens in the source (_ac_build_counter seems to be set in just the one place).

gregnoel said at 2008-12-26 13:29:14

Adjust triage of issues.

stevenknight said at 2009-11-10 18:00:19

stevenknight => issues@scons

[bdbaddog]

Perhaps clean all configure output files if interrupted? I think handling the simpler case has value..