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 generators_prototype.py
>>hacking.txt nightly.sh release_procedure.txt roll.sh
>>End users don't need these files. So moving them deeper will make the
> 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
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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk