Boost logo

Boost :

Subject: Re: [boost] [fiber] new version
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-15 20:45:39


----- Original Message -----
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 12, 2010 8:59 PM
Subject: Re: [boost] [fiber] new version

 
> Am 05.05.2010 09:34, schrieb Vladimir Prus:
>> Oliver Kowalke wrote:
>>> I've uploaded a new version of boost.fiber (0.4.2) to boost-vault. The
>>> context/stack swapping is implemented in assembler for i386 and x86_64
>>> (see documentation).
>>>
>>> Because of the limitations of boost.build you have to compile bjam
>>> with python support (see docu of boost.fiber).
>>
>> We probably need to talk again about your requirements and how to address
>> them -- for I never understood them fully. Requiring python-enabled bjam
>> seems premature for this.

> Hello Vladimir,
>
> boost-fiber implements some code in assembler (no inline-asm) for
> different platforms (OS and architecture).
> In order to select the correct assembler code I need:
>
> - architecture/instruction set (i386,x86_64, ppc, arm, ...)
> - memory-model (32/64 bit)
> - binary format (elf,mach-o, windowpe)
>
> Boost-build already defines properties
> <architecture>,<instruction-set>,<memory-model>. Unfortunatly as
> optional properties - so I can not rely on it in the Jamfile (I
> alreadytried to use them but they where never set on 64bit Linux+
> gcc-4.x -> bjam --debug-build).
> For the binary format I didn't found an property provided by boost.build.
>
> I was forced to use the python support in bjam which will proprably
> annoy users.

I think that we can not force the user to install a specific bjam version.

Volodya, do you confirm what Oliver is saying? Can Boost.Build solve these issues without using Python?

Oliver, in the mid time, could't you let the user states these properties explicitly either on the command line or on the site config file, when not provided by Boost.Build?

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk