Re: [Boost-build] [future] Implementation language(s)..

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_INTERFACE(foo,
     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;
};

BOOST_PLUGIN_EXPORT_CLASS(plugin_foo, foo);

void function(plugin_foo&, const string &);

#in plugin.py
def py_foo(foo):
     def bar(self, i):
         print(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("plugin.py");//determined by the extension
pm.load<plug::dll_provider>("plugin.dll"); //explicitly set

auto ct = pm.content("plugin.py"); //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) >= 
fs::last_write_time(out);}
     virtual void update() {fs::copy(in, out);}
};

BOOST_PLUGIN_EXPORT_CLASS(copy, generator);

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.