Re: [boost] 1.43 build broken on MSVC 8.0

Subject: Re: [boost] 1.43 build broken on MSVC 8.0
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-05-22 00:45:43

On Fri, May 21, 2010 at 8:41 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> On 5/21/2010 8:53 PM, OvermindDL1 wrote:
>>
>> On Fri, May 21, 2010 at 12:52 PM, Steven Watanabe<watanabesj_at_[hidden]>
>> Â wrote:
>>>
>>> AMDG
>>>
>>> Rene Rivera wrote:
>>>>
>>>> On 5/21/2010 1:06 PM, Beman Dawes wrote:
>>>>>
>>>>> IIUC, the OP used this command line after a booststrap:
>>>>>
>>>>> Â  Â  ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared
>>>>> ...
>>>>>
>>>>> and Volodya replied that "Neither--architecture=amd64 nor
>>>>> --address-model=64 ever worked."
>>>>>
>>>>> Thus the comment about the possibility of adding a check for
>>>>> non-existent switches.
>>>>>
>>>>> Providing some options that require no "-', some that require "-", and
>>>>> some that require "--" may make sense from an internal perspective,
>>>>> but this is terribly confusing to the user. So the user often makes
>>>>> mistakes. To have the mistakes silently ignored makes it difficult or
>>>>> impossible for the ordinary user.
>>>>
>>>> Ah, yes, we've had that come up before.. Unfortunately the "--" options
>>>> are an open set. So it's rather hard to actually detect when those are
>>>> non-existent.
>>>
>>> Is there some way that we could mark options as used?
>>> Could we require everything to go through the options
>>> module instead of doing a raw match against ARGV?
>>> At least, would it be reasonable to warn about arguments
>>> that would look like properties if they didn't have the --?
>>
>> We have a library in Boost to handle all this, why is it itself not
>> used? Â If it is because of missing functionality, that indicates
>> something in that library that should be fixed. Â As I recall,
>> program_options also warns about incorrect flags.
>
> Yeah.. Except bjam is written in "C" ;-) And even if it where in C++, which
> I'm considering doing, the nature of bjam as an interpreted ad-hoc modular
> language interpreter doesn't lend itself to pre-declaring such options. But
> what Steven suggest is the only way I've though about to handle it.

<fanciful-ideas>
Well if it was re-written, and felt like rewriting the bjam source
too, the latest Spirit has developed an infinitely extensible
S-Expression based language designed for such C++ embedding as an
example.
</fanciful-ideas>