Re: [jamboost] boost-build.jam documentation issues

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
>>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?

Andrey