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