Re: [Boost-build] Jamfile feature request - bjam version check

Subject: Re: [Boost-build] Jamfile feature request - bjam version check
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-12-07 08:08:38

Vladimir Prus wrote:
> Beman Dawes wrote:
> 
>> We are trying to make the boost doc build more robust. I just ran into a
>> problem because my version of bjam was older than the version required
>> by the doc Jamfile. This is, of course, entirely my fault, but it would
>> be very helpful if an explicit error message appeared telling me what an
>> idiot I am for forgetting to keep my bjam up to date.
> 
> Please tell:
> 
> - The exact problem you run into

My bjam build was 03.1.17, but the boost-root/doc/Jamfile requires 03.1.18.

> - What environment you're using
>         - Is this GNU/Linux, or MS Windows, or GNU/Kernel32.dll

This particular time the problem surfaced running under Windows/Cygwin 
using the bash shell.

>         - What is line ending of your Boost checkout

This particular run was done on a Unix line ending checkout.

> - What are the first 10 lines in Boost.Boost output

What is "Boost.Boost output"? Also, I've since updated bjam, so I can't 
easily reproduce the problem.

> 
>> This isn't the first time that I've had problems because a certain
>> version of bjam was required for some build to work. Perhaps Jamfiles
>> could have a feature that says, in effect, "version n.nn or later of
>> bjam is required, but the current version is earlier than that."
>>
>> If this  condition isn't met, the build should terminate with a clear
>> error indication.
> 
> You might want to check 
> 
>         http://permalink.gmane.org/gmane.comp.lib.boost.testing/6110

Yes, but the I'm running chron scripts. There is no human reader to see 
that message. That warning needs to turn into a hard error that aborts 
the run. If that isn't appropriate as the default behavior, perhaps an 
--non-interactive switch could turn it on. svn, for example, uses that 
approach.

> 
> In short, because trunk tests are using fixed release of Boost.Jam,
> hard error is impossible in general.

This problem surfaced in doc builds, not trunk tests.

--Beman