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

Subject: Re: [Boost-build] RFC: Boost.Build Python Prototype
From: Ryan Gonzalez (rymg19_at_[hidden])
Date: 2016-11-14 15:44:29

So, some comments:

- HOLY CRAP that logo is awesome! :D

- This kind of irks me:

default = 'hello'

Seems odd for there to be ONE module-level, magic variable. Maybe something
like `set_default('hello')` would be better?

- What's the significance of the action's name? Pretty much every time,
you're just using the return value. Is it just for error messages?

- Actually, in general, I think the whole string vs return value think
could be kind of confusing. For instance, default is a string for the
target name, and you use it to reference the object files in the first
examples, but then you use the return value in the Composite Targets
example. What exactly is the difference?

On Mon, Nov 14, 2016 at 1:54 PM, Stefan Seefeld <stefan_at_[hidden]> 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.
> Conceptually this is quite similar to Boost.Build V2 (with a few
> noteworthy exceptions mentioned in
> https://stefanseefeld.github.io/boost.build/doc/html/introduction.html).
> Most of the differences are syntactic in nature, as I'm using Python
> (Doh!). I'd like to convince you that this is an elegant yet powerful
> language to write build logic in. Indeed, I believe that there is a
> smooth path from beginner (i.e. the minimum of Python you need to
> understand to be able to read and write simple build scripts) to
> advanced (the knowledge you need to be able to write Boost.Build
> extensions, such as new tools, or new composite targets.), and in fact
> that by adopting this frontend will allow Boost.Build to gain a much
> wider audience. (I paid particular attention not to let any
> domain-specific assumptions slip into the model. For example, while
> Boost.Build V2 presents itself as a tool "...to build C++ projects", I
> believe it's easy to make it useful to other use-cases, too.
>
> To support this Python interface, I applied a few patches to the C
> engine below. (In fact, the major patch consisted in refactoring the
> Python module definition into its own .c file.) These changes are
> however all fully backward compatible, so it should be possible, if not
> easy, to merge these changes into the existing engine and then support
> the original Jam and the new Python interfaces at the same time.
>
> I did opt to reconsider the lowest interface (using the "bjam" module),
> rather than code that integrates into the existing Python interface, as
> this gave me greater flexibility in exploring possible new Boost.Build
> foundations. This implies that, to augment the functionality of this new
> interface, it's probably not very useful to attempt to translate all the
> existing .jam files in Boost.Build. It's far more  efficient to rewrite
> the equivalent Python code (tools and targets mostly, I believe) from
> scratch, once the remaining issues in the general design and
> implementation are fleshed out.
>
> The current code is in the "proto" branch in
> https://github.com/stefanseefeld/boost.build
>
> I'd appreciate any and all feedback,
>
>
>         Stefan
>
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost-build
>

-- 
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://kirbyfan64.github.io/