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

I'll try and take a look at your example repo over the next few days and
see I can get it to work.
-Bill

On Wed, Jan 5, 2022 at 7:42 AM Mats Wichmann <[email protected]> wrote:

> 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.
>
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users