Re: [Boost-build] RFC: Boost.Build Python Prototype

Subject: Re: [Boost-build] RFC: Boost.Build Python Prototype
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-11-15 08:02:03

Hi Vladimir,

On 15.11.2016 02:42, Vladimir Prus wrote:
>
> Hi Stefan,
>
> On 14-Nov-16 10:54 PM, Stefan Seefeld wrote:
>> Hi there,
>>
>> A few weeks ago I started to look into a new Python frontend for
>> Boost.Build. After quite a few nights of exploration, I'm now happy to
>> present first results:
>>
>> In https://stefanseefeld.github.io/boost.build/doc/html/index.html I
>> describe a few examples of how to write build logic with this prototype.
>
> I appreciate your putting together a prototype of how things might look
> in pure Python!
>
> However, I am not sure I agree with the direction your prototype took.
> The key parts of Boost.Build design are metatargets, portable properties
> and generators. Looks like you've dropped all of that:

I didn't mean to drop any essential functionality. So perhaps we can
take the opportunity to spell out use-cases and see how they are
implemented in BB V2 as well as my prototype.
(Please note that my prototype is just that: a proof-of-concept. And
especially since I have attempted a "bottom-up" / layered approach, it
may appear as if I let all the low-level stuff (such as explicit
actions) creep into the interface, when what really matters are
high-level abstractions. I'm fully aware that even as a prototype this
is fairly incomplete, in particular as far as "composite targets" and
their interface is concerned. It wasn't my intent to present the current
state as a proposal for what to replace BBV2 with, but rather, how to
approach the development of the missing features.)

>
> - Yes, metatargets are complex parts of Boost.Build, but I think it's
>   an essential parts. The fact that you can generate a metatarget with
>   different properties gives quite some flexibility - in particular
>   Boost users that to build multiple variants of the libraries, and run
>   tests in different combination of properties. When you say that it's
>   easy to chain some invocations, I think you just gloss over the issue.

Can you demonstrate (by virtue of a use-case) what I'm missing by not
supporting multi-variant builds ? What is the difference (in
functionality) between `b2 --toolchain=gcc,clang` and `b3 --tool=cc:gcc
&& b3 --tool=cc:clang` ?

>
> - You also seem to not have any notion of portable build properties -
>   instead each tool just accepts whatever it pleases. I can't see any
>   support for automatically generating build directories based on
>   properties. There does not seem to be any support for computing final
>   build properties based on requested ones.

You are right, that is still missing. Indeed, my putting together the
mechanism for communicating properties across targets felt quite ad-hoc,
and I would like to consolidate that into something more formal. I'd
appreciate your help with that ! :-)
And for avoidance of doubt: I'm not at all against establishing build
directory naming conventions based on properties. I just don' want to
bake that into the tool itself, i.e. I'd rather make that something that
can be "plugged in" per project.

>
> - Looks like the action/target mechanism basically reimplements all
>   of Boost.Build generators

Yes, that is indeed my goal. Is there anything fundamentally wrong with
that approach ? (I'd rather avoid layering the Python front-end on top
of a Jam layer, as that leads to overly complex (and thus rigid) code.
It is the underlying idea that is important and useful to preserve. So
again, can you demonstrate (ideally by virtue of a few use-cases) how my
suggested approach isn't able to serve the requirements ? Or is this
strictly about terminology, i.e. BBV2 calling it "generators" and me
calling it "composite targets" ?

Many thanks for your feedback !

        Stefan

>
> If you believe the above mechanisms are not necessary, then why don't
> you think SCons is the answer?
>
> Thanks,
> Volodya
>
>
>

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