[Scons-users] Hierarchical builds not possible (TAR/RPM packaging)

[Werner Reisberger]

On 2022-01-05 16:42, Mats Wichmann wrote:
...
...
> Part of the problem is both statements are true as far as they go, and
> there's context involved.
> 
> The statement about by default changing directories refers to the scan
> phase of operation.  As a given SConscript is processed, it is 
> processed
> in the context of the directory in which is appears, unless you told it
> not to.  Although it's not the most insctructive example in the world,
> there's a test that shows this in action:
> 
> https://github.com/SCons/scons/blob/master/test/SConscript/SConscriptChdir.py

Thanks for explaining this. I was not aware of this difference between 
the scanning and building phase.

I therefore had to rename the SConscript file in the rpm BUILD directory 
to SConstruct because the recursive scons call (within the rpm SPEC 
file) has no information about the original call from the upper level.

Probably this problem is easier to solve by splitting up the RPM build 
process into separate builder. One additional for the spec file and a 
final one calling rpmbuild. Going this route could also offer you more 
flexibilty in the way rpmbuild is called. Currently you can call it only 
with the "-ta" option which means that it expects a tar file with 
sources and spec file combined.

--Werner

> The SConscriptChdir stuff is only for the script scanning phase, when
> you are capturing information, it has no effect during the build phase.
> 
> The information collected during the processing of an SConscript is
> mainly captured in the form of Nodes, of which SCons builds a tree -
> that's the objective of the scan phase. If you asked for a program 
> "app"
> to be built from source file "app.c", there will be a Node for each.
> The app.c node is able to refer to the disk file since it exists, while
> the app node captures that it depends on the app.c node, and that a
> particular builder is needed if app (if the disk file exists) is out of
> date with respect to that node (plus lots more information).
> 
> The nodes include how to locate themselves relative to the project 
> root,
> so when it comes time for the build phase, the User Guide statement
> about staying at the top level *when commands are issued* can be true,
> because the information exists to do so.  In fact the section heading 
> of
> the user guide section you pointed to is actually restating the manpage
> claim about SConscripts in different wording:
> 
> 14.2 Path Names Are Relative to the SConscript Directory
> 
> 
> 
> The packaging code for rpm is particularly convoluted because there's a
> standard SCons-type build, where some external tool is called, but that
> tool is rpmbuild, which processes the specfile which that SCons run has
> constructed, which contains instructions to call scons again in the 
> form of:
> 
> %install
> scons --install-sandbox="$RPM_BUILD_ROOT" "$RPM_BUILD_ROOT"
> 
> 
> So now the challenge is to sort out how to make the docs better, and
> what all is broken in the packaging code in general and rpm packaging
> specifically.  Clearly the Tag code has problems.
> 
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users