On Fri, May 21, 2010 at 8:41 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 5/21/2010 8:53 PM, OvermindDL1 wrote:
On Fri, May 21, 2010 at 12:52 PM, Steven Watanabe<watanabesj@gmail.com> 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>