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-20 19:37:31

On 5/20/2013 4:16 AM, Vladimir Prus wrote:
> On 18.05.2013 16:14, Edward Diener wrote:
>> 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.
>
> For example, here are two versions output by gcc on my system
>
>      gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>      gcc version 4.7.3 (Sourcery CodeBench 2013.05-21)
>
> Both of them have a bunch of additional patches relative to FSF
> versions, and gcc build process provides a lot of knobs, and
> even if we talk about any major feature introduced in 4.7 it quite
> possible that this feature does not really work on
> ARM GNU/Linux targets. So checking for compiler version is not a very
> good solution.

It is a good solution when the end-user needs it. A typical case is a 
compiler feature implemented at some known major/minor level. But that 
is irrelevant since lots of other practical cases can be made for its 
use. You are just coming up with a particular argument, generalized or 
specified to support your case. I could just as well say that using a 
full version number is not a very good solution using the same, or 
similar, statements you make above. Of course user's of Boost Build use 
the full version number all the time so that they can have finer control 
of the build process.

>
> In some cases, yes, useful decisions can be based on compiler version,
> and we have access to it for gcc, and we don't expose
> it to Jamfiles in a particularly useful way. Part of the problem is that
> doing this is possible in either ugly way, or backward
> incompatible way.

I have no idea how "ugly" it would be but I do not understand the 
backward-compatibility issue. Is "gcc-4.7" accepted by Boost Build ? Is 
"gcc-4" accepted by Boost Build ? What do they mean ? I would have 
thought, from my own use, that one must specify the full version, ala 
"gcc-4.7.0". If that is not the case, and "gcc-4.7" means "gcc-4.7.0' 
and 'gcc-4' means 'gcc-4.0.0' then I would break backward compatibility 
and change it to support the sort of changes I suggest. Even if you did 
not want to break backward compatibility, it is supremely easy to come 
up with an alternative workable syntax for compiler-major-minor or 
compiler-major notation.

I generally don't mind ugliness if the syntax is usable and 
understandable. If you like I would be glad to suggest a syntax for all 
of the functionality I suggest in my scenario.