Boost logo

Boost-Build :

Subject: Re: [Boost-build] Port to z/OS
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-06-12 14:07:34


On Mon, Jun 12, 2017 at 4:04 AM, Groke, Paul via Boost-build <
boost-build_at_[hidden]> wrote:

> Now my questions
> 1) The CONTRIBUTING page says to create patches and post them to the
> mailing list. Is this still current, or can I use github - i.e.
> fork/push/create pull-request?
>

Use github.

> 2) I'm puzzled as to why the Boost.Build engine uses FILE* streams on
> UNIX-like platforms (execunix.c) and not raw file descriptors when reading
> output of the child processes. Do you think it would be acceptable to
> change that code to simply use the "raw" file descriptors on all platforms?
> AFAICT the only real difference should be buffering, and I don't think the
> buffering that FILE* provides is important for that use case.
>

I don't remember why this is.. Other than it's old ANSI-C code. Not sure
how I feel about using raw files.

> 3) Do you think it would be acceptable for a z/OS port to simply not
> support getting "system" and "user" times for child processes (e.g. by
> simply setting them to zero)? Or is there a simple way to reliably get the
> system/user times for *one* child process when using waitpid?
>

I guess zero is fine initially. It just means any reporting that uses those
numbers will be incorrect. I.e. I don't know of uses cases where the
numbers are used that will fail if they are zero.

> 4) Is there some documentation/guideline for writing new compiler support
> files ("tools/xlcpp.jam" etc.)?
>

Not explicitly, AFAIK. But you should read through the extender chapter of
the docs <http://www.boost.org/build/doc/html/bbv2/extender.html> at least.
And use existing toolsets as examples.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail


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