Re: [Boost-build] question(s) about bjam code III

Subject: Re: [Boost-build] question(s) about bjam code III
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-10-25 15:28:37

AMDG

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 
> https://github.com/boostorg/build/blob/develop/src/engine/function.c#L5233).
> 
> 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.

In Christ,
Steven Watanabe