question(s) about bjam code III

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

question(s) about bjam code III

Boost - Build mailing list

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.

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.

Thanks,

Stefan
-- 

      ...ich hab' noch einen Koffer in Berlin...
    

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: question(s) about bjam code III

Boost - Build mailing list
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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build