Boost logo

Boost-Build :

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-29 08:57:18

Am 18.10.2016 um 15:59 schrieb Rene Rivera:
> Before we too far ahead of ourselves we have one particular decision to
> make.. What do we write the next Boost Build in? Starting with the rough
> modules.. It shows some possibilities:
> Project Descriptions DSL (i,e, Jam), Python, Lua
> Extensions C++, Python, Lua, Haskel
> Build System C++, Python, Lua, Haskel
> Target Graph C++
> Scheduler C++
> Executor C++

Concerning the extension languages, I proposed to offer several
languages to extend boost.build3. I didn't have the time
to actually implement this, but I am quite certain that something like
this could be possible as a plugin system.
I hope it gives you an idea how I imagine this to work and why - since
it provides a common interface - this does not turn a program using it
into a mess. It could in theory provide many more languages, and the
implementer of the core logic would never know of it.

I'm not sure about the plain functions, but it still gives an idea of
how this could look. Maybe this could also become a library for boost; I
would however like to check if there's interest for something like that,
because that will take a lot of time to implement. And if it becomes a
library, I'd need to get informations on what other stuff people might
want to do with this.

So, to give you an idea, of what I envision, here's some sample code,
that is hopefullye close to what such a library could look like.

//declaration of the interface in the program with the plugin-system -
since we do not have reflection.
     BOOST_PLUGIN_MEMBER_FUNCTION(bar, void(int));
     BOOST_PLUGIN_VIRTUAL_FUNCTION(thing, std::string(), const);
     BOOST_PLUGIN_STATIC_FUNCTION(stuff, size_t());
     BOOST_PLUGIN_MEMBER(value, int);

BOOST_PLUGIN_FUNCTION(function, void(foo&, const string&));

//in plugin.cpp
struct plugin_foo : foo
     void bar(int);
     virtual std::string thing() const;
     static size_t stuff();

     int value;


void function(plugin_foo&, const string &);

def py_foo(foo):
     def bar(self, i):
     def thing(self):
         return "test string"
     def stuff():
         return 42
     value = 42

def function(foo_, strng):
     return None

//ok, now use it in our code
namespace plug = boost::plugin;
using plugin_manager = plug::plugin_manager<plug::dll_provider,
plug::python_provider /* and maybe other */ >;

plugin_manager pm;

//first way: add a listener, who get's informed for any overload.
//type_info would be able to construct the thingy.
pm.add_listener<foo>([](plug::type_info<foo> & foo_inst){});

//alright, now load the plugins:
pm.load("");//determined by the extension
pm.load<plug::dll_provider>("plugin.dll"); //explicitly set

auto ct = pm.content(""); //some way to evaluate the content.

//ok, we are able to also able to construct the type directly, or from
the type_info
plug::plugin_ptr<foo> p = pm.make<foo>("py_foo"); //no args needed for
the ctor.
p->thing(); //trivial, is virtual
p->bar(42); //calls the wrong function.
p.get("bar")(42); //calls the implementation
p.get("value"); //gives the value

//now for the plain function, I'm not as sure, but maybe this:
pm.invoke<foo>("function")(p, "stuff");

//or maybe the BOOST_PLUGIN_FUNCTION declares a global, so we can just
do this:
function(p, "stuff");

As for the use in b3, I'd think you'd use the listener pattern, take the
type_infos, and put them into the generator. I.e. the plugin could look
something like that:

struct copy : boost::build::generator
     fs::path in;
     fs::path out;
     copy(fs::path & in, fs::path & out) : in(in), out(out) {}

     virtual bool needs_update() {return fs::last_write_time(in) >=
     virtual void update() {fs::copy(in, out);}


Or some equivalent in python.

Please let me know if you consider this ugly, insane, dangerous or in
fact useful. I think this could be a neat system to allow easy
extensions of the build-system, but there are many corner-cases with
that, so it's all but trivial.

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at