Re: [Boost-build] bjam 4.0.. in C++

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2010-05-23 12:03:33

On 05/23/2010 11:55 AM, Rene Rivera wrote:
> On 5/23/2010 1:00 AM, Spencer E. Olson wrote:
>> My two, three, or four cents on the matter:
>
> Thank you for these.. It's making me think hard about the choices..
>
>> 1.  Issue with Boost dependence:
>> One of the main advantages of bjam currently is that it is written in 
>> ansi c
>> and compiles very, very easily and very quickly for every platform I 
>> have to
>> work with.  Currently, bjam is not a heavy weight piece of code that is
>> difficult to "carry" from machine to machine, let alone compile.  As 
>> a contrast,
>> think of the "other" main contender for boost attention: CMake.  
>> CMake is both
>> gigantic, a pain in the neck to compile (yes, Kitware does provide 
>> prebuilt
>> versions for many platforms already--but I prefer the small 
>> footprint, easy-
>> to-move-and-compile bjam).
>
> I certainly prefer a small footprint with quick compiles.. But I have 
> yet to find a lightweight parsing solution for C++ (i.e. that plays 
> nicely with C++) that is lightweight enough to be packaged with bjam. 
> They either all require some largish external program or don't play 
> nice with C++.

Why do you insist to do the parsing in C++ ? Why not use a scripting 
language (lua, python) for it ?

>
>> If you have bjam rely on any part of boost that can't be repackaged and
>> shipped with bjam code, the portability of bjam quickly becomes a 
>> nightmare.
>
> True. Which makes it harder since under the plan of depending on Boost 
> I would not prepackage it with bjam. Instead depending on the user to 
> have it around. Which indeed does complicate the setup.

Circular dependencies is one of the core issues in boost. Having the 
boost build system depend on boost only makes it worse.

Regards,
         Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...