Re: Hierarchical builds not possible (TAR/RPM packaging)

On 1/5/22 01:39, Werner Reisberger wrote:

> BTW: You advise against using SConscriptChdir(1) but this isn't working
> anyway. I couldn't see any effect using this call with any parameters.
> 
> I also think that the statement on the SCons man page (in the
> SConscriptChdir chapter) is wrong:
> 
>>>> By default, scons changes its working directory to the directory in
>>>> which each subsidiary SConscript file lives.
> 
> According to the tests I did the below quoted statement on the SCons
> user page is right.
> 
> I regard man pages as reference for the usage of a tool. They should be
> as clear and error free as possible.
> 
> --Werner

Sure.  I've been on a campaign to improve the docs over the past couple
of years, and we'll fix up what's unclear here. The challenge being to
figure how to say what's needed completely but still somewhat concisely.
The below will probably fail the concise test, fwiw.

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

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.