Re: [jamboost] Re: Bjam memory use -- Was: [BBv2] [msvc] Remove c all to vcvars.bat

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-06 08:01:59

"MANSION, James, FM" <James.MANSION_at_[hidden]> writes:

>> We can provide pre-built single bjam executables that hide the existence
> of Python from any install process.
>
> I don't believe this, sorry. What versions of DragonFly BSD will you
> support? Which PPC Linux? Solaris on Intel?

:)

> There's just too much variety - admittedly much of it pointless really.

Maybe so. But is building Python really a challenge on all of those
platforms? IIUC it's extraordiarily portable.

>>Well, it's avoidable, but quite painful. We have lots of problems that
> will be very hard to solve without such >a transition:

<schnipp>

> So, we are saying that the current language is painful. Python
> isn't a build-system language either so you implement a build-system
> language with Python. 

Wait, wait wait! The problem is that the current language *is* a
build system language, and for a system with the level of abstraction
in Boost.Build, we need a general-purpose one.

> What's to say that the same mistakes won't be made again, albeit
> with a more productive implementation language than C?

I don't know what mistakes you're referring to. Any "mistakes" cited
above were designed into, and inherited from, Perforce Jam. Of course
you could assume that we'd make exactly the mistakes we're trying to
fix in any rewrite, but I tend to think we're not that stupid.

> Why not just reviisit what primitives are desired, and build a better
> language to do it?

- We don't have time. Language design is not our central mission
here; that should be left to language design experts.

- We don't want to have to maintain our own language

- We want a language that's well known to a broad cross-section of
programmers, and easily learned by the others.

> Or at least build a set of primitives and then hook to a smaller
> system like Pike or LUA.

- We want a language that's well known to a broad cross-section of
programmers, and easily learned by the others.

Also, Python can be made quite small. You don't need to bundle most
of the libraries into it, and the core interpreter is quite manageable
in size.

> Do you know how feasible it would be to subset Python and include it
> directly so that it could be built wit a simple bootstrap.cmd or
> bootstrap.sh without intervention?

No. I'm not sure why we'd want to do that, anyway. I want to use the
work that the Python maintainers have put into defining autoconf
stuff, which causes Python to build reliably on a wide variety of
platforms. I don't want to try to maintain our own parallel version
of that code which could fail over and over again in different
contexts until we tweak it into a state of unmaintainable complexity.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com