<div dir="ltr"><div>If you'd like some consulting help with this, I'm available.</div><div>( <a href="http://www.baddogconsulting.com">www.baddogconsulting.com</a>)</div><div><br></div><div><br></div><div>Can you roll back your SCM (git) to a point where the build still works?</div><div>(Use git bisect if you're using git)</div><div>That may be the easiest way to track down what changed.</div><div><br></div><div>-Bill</div><div>SCons Project Co-Manager<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 6, 2025 at 9:38 AM Mats Wichmann <<a href="mailto:mats@wichmann.us">mats@wichmann.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/6/25 09:58, summerrain1--- via Scons-users wrote:<br>
> Hello folks,<br>
> <br>
> first peek into this list, and been fiddling with a SCons build<br>
> structure for a somewhat complex project for a couple days.<br>
> <br>
> Unfortunately I'm not going the route of learning this system by<br>
> starting with a small, simple project and making baby steps, but am in<br>
> the less than enviable position of being tasked to fix a build system<br>
> left by a "defected" colleague, which used to work, and now doesn't ;)<br>
<br>
Sympathies. Yes, this does happen a fair bit (how I was introduced to <br>
SCons about 8 years ago).<br>
<br>
> I have been trying to do things like add print or Debug.Trace statements<br>
> to SConscript files within the deep project hierarchy where I thought<br>
> illuminating when what happens may be promising.<br>
> But turns out there is no time correlation between when prints are put<br>
> on the console and when build steps actually happen, because the prints<br>
> are apparently all done when the system reads all the SConscript files.<br>
<br>
Yes, there's what you could think of as two-pass behavior.  All the <br>
sconscripts are read and a dependency tree is built.  In this phase, all <br>
the "pure Python" that is not embedded in callback functions executes. <br>
Then the completed tree is handed to the taskmaster which figures out <br>
what needs (re)building, and dispatches workers to do so.<br>
<br>
Everything that actually builds is done via Actions, which don't run <br>
until they are needed. Also, the command lines that make up many of the <br>
Actions are written in a mini-language that allows for variable <br>
substituton, this also does not happen until it's actually needed. For <br>
example, the line to build from a C source file with gcc is:<br>
<br>
'$CC -o $TARGET -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES'<br>
<br>
That ends up stored in a variable in your construction environment <br>
called CCCOM.<br>
<br>
The variable references are expanded recursively, so _CCCOMCOM, which is:<br>
<br>
'$CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS'<br>
<br>
has to be further expanded, etc.<br>
<br>
This means you have to think a bit about how to debug, as you've found. <br>
Debug prints are great for the first phase, and if you're downloading <br>
things are you indicate further down, you should be able to diagnose <br>
those things fairly easily.<br>
<br>
> Is there still a way to do "printf style debugging" this?<br>
> Is this even a good idea, or are there better ways to go about it?<br>
> I have seen one stackoverflow thread with suggestions of installing some<br>
> fancy IDE to debug the build scripts step-wise based on Python, but this<br>
> is a headless remote server & I can't do that.<br>
<br>
Some places, prints work fine.<br>
<br>
> I am having problems like the build failing due to some missing file,<br>
> but no indication in the console output as to why and where it may have<br>
> failed to get something.<br>
<br>
Usually, missing header files are due to missing settings in $CPPPATH:<br>
<br>
<a href="https://scons.org/doc/production/HTML/scons-man.html#cv-CPPPATH" rel="noreferrer" target="_blank">https://scons.org/doc/production/HTML/scons-man.html#cv-CPPPATH</a><br>
<br>
Sometimes the way the build is set up obscures information, and if so <br>
you may wish to remove some of the obscuring.  The build actions have <br>
corresponding string functions that say what to print when that step is <br>
executed (if omitted, the whole command line is emitted).  If you're <br>
seeing brief lines like<br>
<br>
Compilng src/foo/x.c<br>
<br>
you might want to go look for settings of variables like CCCOMSTR and <br>
temporarily comment those out.<br>
<br>
Let us know if these are other kinds of missing files... sometimes <br>
generated sources don't get generated, external dependencies don't get <br>
put into place, and so forth. We may be able to recognize some messages.<br>
<br>
> Trying to get a picture of things just with grep is eating a lot of<br>
> time. Though I did fix one of these type of issues which turned out to<br>
> be hard-coded access tokens to download fixed archives of components,<br>
> which were expired & the build did not stop there despite those files<br>
> failing to download - intead things exploding later... (and it wasn't<br>
> even in SConscript or other clearly script type files, i.e. I'm grep'ing<br>
> all files...)<br>
<br>
As mentioned, getting "externals" or "third party" bits in place can be <br>
a challenge, so definitely keep checking that. There are some tricks to <br>
getting those in place so SCons can track them, rather than just <br>
declaring not found and giving up.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Scons-users mailing list<br>
<a href="mailto:Scons-users@scons.org" target="_blank">Scons-users@scons.org</a><br>
<a href="https://pairlist4.pair.net/mailman/listinfo/scons-users" rel="noreferrer" target="_blank">https://pairlist4.pair.net/mailman/listinfo/scons-users</a><br>
</blockquote></div>