No longer builds after scons -c #330

Closed
opened 2023-01-28 18:16:01 +00:00 by x-qq · 2 comments
x-qq commented 2023-01-28 18:16:01 +00:00 (Migrated from github.com)

Running scons -c inside the git checkout directory where build worked before somehow leads to this:

% scons
scons: Reading SConscript files ...                                           
Building for: posix
Using toolchain: default
C++ compiler: g++
Checking whether the C compiler works... no
There's a problem with your compiler!

Removing .sconsign.dblite seems to fix it.

Running `scons -c` inside the git checkout directory where build worked before somehow leads to this: ``` % scons scons: Reading SConscript files ... Building for: posix Using toolchain: default C++ compiler: g++ Checking whether the C compiler works... no There's a problem with your compiler! ``` Removing .sconsign.dblite seems to fix it.
NQNStudios commented 2024-05-25 03:19:23 +00:00 (Migrated from github.com)

I'm able to reproduce this.

Here's what I dug up about .sconsign.dblite:

The .sconsign.dblite file is a temporary database used by SCons to keep file signatures to speed up future builds. If you delete it, SCons will recreate it (and your next build might take slightly longer because of that). It should not be put under version control.

(from https://stackoverflow.com/a/12867804)

So, SConstruct is marking that file for deletion, and it's getting recreated after scons -c is called.

Weirdly, scons -c still creates this bug, even after I tried changing SConstruct to not mark the dblite file for deletion.

I'm able to reproduce this. Here's what I dug up about .sconsign.dblite: > The .sconsign.dblite file is a temporary database used by SCons to keep file signatures to speed up future builds. If you delete it, SCons will recreate it (and your next build might take slightly longer because of that). It should not be put under version control. (from https://stackoverflow.com/a/12867804) So, SConstruct is marking that file for deletion, and it's getting recreated after `scons -c` is called. Weirdly, `scons -c` still creates this bug, even after I tried changing SConstruct to not mark the dblite file for deletion.
NQNStudios commented 2024-05-25 03:33:33 +00:00 (Migrated from github.com)

The conversation here indicates that you're not supposed to delete .sconsign.dblite from your SConstruct file, but scons -c breaks the next build even if we don't do that, so it seems like we do need to delete it. I tried the weird atexit workaround shown in that issue, and then it worked.

The conversation [here](https://github.com/SCons/scons/issues/2268) indicates that you're not supposed to delete .sconsign.dblite from your SConstruct file, but `scons -c` breaks the next build even if we don't do that, so it seems like we *do* need to delete it. I tried the weird `atexit` workaround shown in that issue, and then it worked.
Sign in to join this conversation.
No description provided.