Subject: Re: [Boost-build] Options for a compiler version
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-05-18 08:14:23
On 5/18/2013 5:01 AM, Juraj IvanÄiÄ wrote:
> On 18.5.2013. 0:55, Edward Diener wrote:
>> Thanks, I will look at it.
> Attaching a much shorter and improved version which works with minor
> version numbers.
>> The condition, which you say is "complex", appears to me as an end-user
>> of a build system to be extraordinarily simple. I just do not understand
>> why Boost Build cannot support natively such a scenario. The scenario
>> itself is so common as to be almost ridiculous. Yet it is difficult to
>> do without knowledge of the bjam language and the workings of Boost
>> Build. I do not think that should be the case.
> I called the condition complex because it cannot be expressed using
> simple feature conditions. It is still quite easy. Boost Build can
> definitely support such a scenario natively, but I don't think it is
> that common as you claim.
The scenario I am encountering, in general, is that some action should
be taken depending on a compiler and its major version number, or
depending on a compiler and its major version and minor version number,
or on a compiler and its version number on up, or on a compiler and its
version number on down, or on a compiler and a range of version numbers,
all of the latter as expressed by any of the notions of major version
number, major and minor version number, or full version number.
It is these scenarios in jam files which I have found to be utterly
common. The obvious reason is that compiler vendors make changes in the
form of features and support for C++ as a compiler evolves, and those
changes very often need to be expressed in a jamfile meant to support a
wide range of compilers and versions. No one who writes jamfiles can be
expected to know, or even anticipate, what every version of a particular
compiler supports, especially for compilers who put out new versions
quite frequently ( gcc is the most obvious example of this ). But the
jamfile writer often does know that for a particular compiler's major
version number, or for a particular compiler's major version number and
minor version number, some feature has been implemented for which the
jamfile has to be changed in order to prevent build errors.
The Boost build system natively supports a compiler in general and a
compiler and its full version number. But it has absolutely no native
support for the notions of a compiler and its major version number or a
compiler and its major and minor version versions. By native I mean a
notation that does not require the end-user to figure out how to write a
new Boost Build system 'rule' himself, ie. how to use the 'bjam' language.
I am not the first one that has run into this limitation of the Boost
Build system. Others have questioned this limitation, both in the past
and quite recently, but the Boost Build programmer(s) have taken no
notice and have been unwilling to natively extend the Boost Build system
to deal with this quite common scenario.
Boost Build is a wonderful build system when one's usage is encompassed
by what it natively offers and one can find out what one needs to do
based on its often incomplete documentation. But I don't think I should
have to learn to master the 'bjam' language and its 'rule' writing
system, as you obviously have, in order to use Boost Build in quite
Thank you for your help and your examples of 'rule' based programming
for Boost Build for a common scenario I have encountered.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk