Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2006-11-29 16:25:00

Rene Rivera <grafikrobot_at_[hidden]> writes:

> David Abrahams wrote:
>> If you look at
>> bjam --v2 --help
>> you'll see a mix of option styles. There's
>> --exec-prefix
>> with two words separated by a hyphen, but there's also
>> --builddir
>> and
>> --buildid
>> I believe --builddir is especially heinous because, IIUC, the
>> official BBv2 option is --build-dir.
> <sracasm> Welcome to the wonderful world of autoconf options. </sarcasm>
> The "--exec-prefix" is what autoconf uses. And the "--builddir" follows
> the autoconf style for things like "--bindir", "--datadir", etc:
> Fine tuning of the installation directories:
> --bindir=DIR user executables [EPREFIX/bin]
> --sbindir=DIR system admin executables [EPREFIX/sbin]
> --libexecdir=DIR program executables [EPREFIX/libexec]
> --datadir=DIR read-only architecture-independent data
> [PREFIX/share]
> --sysconfdir=DIR read-only single-machine data [PREFIX/etc]
> --sharedstatedir=DIR modifiable architecture-independent data
> [PREFIX/com]
> --localstatedir=DIR modifiable single-machine data [PREFIX/var]
> --libdir=DIR object code libraries [EPREFIX/lib]
> --includedir=DIR C header files [PREFIX/include]
> --oldincludedir=DIR C header files for non-gcc [/usr/include]
> --infodir=DIR info documentation [PREFIX/info]
> --mandir=DIR man documentation [PREFIX/man]

I should've known :(

>> This is making it hard for me to
>> give clear and straightforward getting started instructions.
> Yea, clarity, one of the reasons I hate autoconf.

Me too.

>> Can we please settle on one convention? I prefer (by far) the
>> versions with the hyphens.
> Sure... But do we want to stray from the insistent users familiar with
> autoconf options?

Nope :(

>> If there's some need to keep the un-hyphenated options for backward
>> compatibility, can we at least make them undocumented?
> The only backward compatibility would be the configure script (not that
> it works as is anyway),

Needs to be fixed, then.

> and possible user scripts. The former can be fixed, the latter is
> more problematic, but since users would likely need to change such
> scripts to account for the rest of the new BBv2 syntax I wouldn't
> worry too much about it.

Right. I think we'd better keep the autoconf options for our
configure script... maybe it makes sense to keep them for Boost.Build
as well, but simply document them as an allowed alternative. I
actually think that accepting both forms will make the tool easier to
use, since I've very often dropped or added hyphens to configure
scripts and gotten the wrong results.

Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at