Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-12 12:02:27

Vladimir Prus wrote:
> On Friday 12 August 2005 02:13, Andrey Melnikov wrote:
>>>>Do we want to cancel Jam language and rewrite BB in Python?
>>>Probably, eventually. First, we are going to rewrite all of the BBv2
>>>guts in Python. You can build bjam --with-python so that it embeds a
>>>Python interpreter. That allows the jam language to remain for
>>>Jamfiles while we rewrite the internal logic.
>>Do you mean that you are going to rewrite the BB core in Python, while
>>users will still use Jam? Do you want users to start writin Jamfiles in
>>Python one day?
> I think this is in mailing list archives. "One day" this might be good, or
> not. We don't have any decision on that, but initially, the port will use
> *unchanged* syntax for Jamfile.

Do we only want to rewrite BB core in Python instead of Jam, have
C-based Jam interpreter bound to Python and leave Jam syntax as is?

>>>>Not only boost-build in the top directory is misleading.
>>>What's misleading about it?
>>That it points to "kernel". I tried to use example\boost-build.jam
>>(which points to kernel/ too) as a template for my own boost-build.jam
>>and ended with having kernel there.
>>I think it should be documented that it's not a good idea to point to
>>kernel despite it works.
> Yes, it's better to require pointing to V2 root, and forbidding poiting to
> "kernel". IIRC, some time ago V1 and V2 had the same root, so "kernel" suffix
> was necessary. Or maybe there was some other reason ;-)
>>>>Should we move other such useless files to a new subfolder?
>>>What are you assuming is useless?
>>boost-build.jam bootstrap.jam build-system.jam
>>hacking.txt release_procedure.txt
>>End users don't need these files. So moving them deeper will make the
>>structure clearer.
> The first three are really necessary with the current bootstrap mechanism.

I understand that now BB won't work without them. But it isn't a big
deal to add kernel/ prefix to the booststrap mechanism, is it? Of course
this is a low-priority task.

> Others can be moved. To bad we're not switched to Subversion
> yet :-((

Do you mean that Subversion allows to move files and preserve revision
history, and CVS doesn't?

>>>Maybe my site administrator has Python-2.3 installed and I want to
>>>test against a Python-2.4 installed in my personal local directory (or
>>>think GCC versions if you prefer).
>>For VC it isn't possible to have private installations. And if all
>>installations are global, there is no need to have private config files.
> What do you mean? I recally I've used VC install on one machine from another
> one via SMB mount. The second machine had no idea that VC was ever install,
> and the first machine was actually running Linux. Looks like "private
> installation".

This is a very important use case. Thank you for pointing it out. If
such use is possible, we cannot remove environment-based autodetection
in favour of registry-based one.

But how did you use VC from another box? VC8 vsvars32.bat has absolute
paths hardcoded in it, so you have to have to install VC say to Z: and
mount that drive as Z: everywhere. Do you really use it this way?



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