Subject: Re: [Boost-build] question(s) about bjam code III
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-10-25 15:28:37
On 10/25/2017 08:08 AM, Stefan Seefeld via Boost-build wrote:
> Hi Steven,
> my next question concerns bjam's execution of functions. The usual data flow
> consists of actions to be compiled into (sets of) commands, which are then
> executed to update a target.
> Baseline bjam has some mechanism grafted into it to run Python functions, which
> are run at the place where "normally" commands are compiled from actions
> (https://github.com/boostorg/build/blob/develop/src/engine/make1.c#L470 calls
> https://github.com/boostorg/build/blob/develop/src/engine/function.c#L3830 which
> may invoke
> I have been (ab-)using this mechanism in faber to allow Python functions to be
> executed instead of system commands. While this has worked very well, I now
> wonder how to handle errors. How does `function_run_actions()` communicate
> errors back to the caller ? The only callsite I can see is in the `cmd_new()`
> function, and I don't see anything akin to handling errors that the called
> functions (which in bjam are typically jam functions, I gather) may encounter.
It shouldn't be a jam function. It should be the
body of an action block. It cannot contain any
significant logic, except variable expansion.
> While I can certainly set up some global variables to capture error states, I'd
> rather use existing channels to communicate status and error states back to the
> call site.
function_run_actions has no provisions for failure.
Any errors that it encounters are immediately fatal.
I think the return value isn't being used, so you
could try sending the error there.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk