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@seefeld.name> 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