Re: [Boost-build] Options for a compiler version

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 
common situations.

Thank you for your help and your examples of 'rule' based programming 
for Boost Build for a common scenario I have encountered.