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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-10-18 16:53:37

On Tue, Oct 18, 2016 at 11:35 AM, Vladimir Prus <vladimir.prus_at_[hidden]>
wrote:

>
> Rene,
>
> thanks for the write up. I have two brief points to make, might have more
> later.
>
> On 18-Oct-16 4:59 PM, Rene Rivera wrote:
>
> of logic at the project declaration layer; Too big to embed (needs
>> external install and linking); Heavyweight run-time, and hence slower
>> startups.
>>
>
> I am not sure I agree. Python is not tiny, but you can link with the
> interpreter and provide a useful subset of the standard library as
> a zip file, it worked quite satisfactory when we needed to bundle GDB
> with Python support.

Sure.. I've done such embedding. But I don't know if doing that removes the
benefits of not embedding it. For Lua there isn't much of a choice, you
need to embed it for it to be of much use. But for Python not embedding it
seems to provide more benefits. For example, being able to install
packages. Does installing packages work when you are embedding it?

> Also, startup time for Python itself has been
> negligible for me for years.
>

Perhaps things have improved since the last time I needed to embed it. But
perhaps it's also that I was embedding it into the rather limited Xbox360
and PS3 systems. Having said that.. I do have a lofty goal of what the b3
startup build times could be. So that may be affecting my choices. For
example.. I think it's possible to design things such that we can start
building a first target in under 2 seconds from launch.

> Relatedly, I think what we have now is an important factor. It is not
> like we have dozens of people willing to contribute. Python port was
> initially contributed out of the blue by Pedro Ferreira in 2005. Later,
> I had a one-month sabbatical to push it further, which was enough to
> known down many test failures, but not much more. Now, Aaron has been
> working on it. That's not many of people :-)
>

Sure.. But I would expect a bit more people contributing to this new
effort.

So it would seem to me that it's most reasonable to work on what we have,
> and it seems like Python port does not have any fundamental
> limitations, rather than consider completely different alternative.
>

It does seem reasonable, to an extent. When we start thinking of
interfacing with IDEs that are written in other languages it starts getting
messy (assuming we want direct code level integration). For example, VS
would require a C# extension; CLion and Eclipse would be Java. Now it's
possible we can do the integration with a client-server setup, but that
will likely make things slower (obviously depending on the design). So
having a fully functional core as a shared library seems like a good idea
to me.

> It might be great to improve the build engine too, and doing so in C++
> will be better than in C, but it seems to me that core build logic better
> be in Python.
>

Perhaps :-) Don't fully know at the moment. And I'm willing to go down that
route. Since it's easy enough to move things down from Python to C++ as
they match up well as far as functional design.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail