New B2 version, and CI failures.

Rene Rivera

13 Apr 2019 13 Apr '19

1:27 p.m.

As some of you may have noticed, there were some changes to B2 yesterday (4-12). As previously mentioned I merged the start of the B2 C++ engine port to the develop branch. That change included some "improvements" to the building of the B2 executable. One of those improvements may be causing people CI failures. The new build scripts for B2 now respect, and use, the CXX and CXXFLAGS environment variables. As such it means that if you have those set for other reasons it may confuse the B2 build (i.e. bootstrap.sh/bat invocation) and fail that build. If that's the case you will need to clear those variables before invoking boostrap.sh/bat or build.sh/bat. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Show replies by date

Andrey Semashev

13 Apr 13 Apr

4:56 p.m.

On 4/13/19 4:27 PM, Rene Rivera via Boost wrote:

...

As some of you may have noticed, there were some changes to B2 yesterday (4-12). As previously mentioned I merged the start of the B2 C++ engine port to the develop branch. That change included some "improvements" to the building of the B2 executable. One of those improvements may be causing people CI failures. The new build scripts for B2 now respect, and use, the CXX and CXXFLAGS environment variables. As such it means that if you have those set for other reasons it may confuse the B2 build (i.e. bootstrap.sh/bat invocation) and fail that build. If that's the case you will need to clear those variables before invoking boostrap.sh/bat or build.sh/bat.

In Boost.WinAPI, with which I have reported the problem, I'm not setting CXX or CXXFLAGS. Regardless, I tried unsetting these variables before running bootstrap just in case they are set in the environment. It didn't help. https://ci.appveyor.com/project/Lastique/winapi/builds/23824813/job/nv2g992b...

Rene Rivera

8:16 p.m.

On Sat, Apr 13, 2019 at 11:56 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

...
As some of you may have noticed, there were some changes to B2 yesterday (4-12). As previously mentioned I merged the start of the B2 C++ engine port to the develop branch. That change included some "improvements" to

...
building of the B2 executable. One of those improvements may be causing people CI failures. The new build scripts for B2 now respect, and use,

On 4/13/19 4:27 PM, Rene Rivera via Boost wrote: the the

...
CXX and CXXFLAGS environment variables. As such it means that if you have those set for other reasons it may confuse the B2 build (i.e. bootstrap.sh/bat invocation) and fail that build. If that's the case you will need to clear those variables before invoking boostrap.sh/bat or build.sh/bat.

In Boost.WinAPI, with which I have reported the problem, I'm not setting CXX or CXXFLAGS. Regardless, I tried unsetting these variables before running bootstrap just in case they are set in the environment. It didn't help.

https://ci.appveyor.com/project/Lastique/winapi/builds/23824813/job/nv2g992b...

Well, that's interesting, and strange given that such a label does exist < https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

...

.

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Peter Dimov

9:09 p.m.

Rene Rivera wrote:

...

...
https://ci.appveyor.com/project/Lastique/winapi/builds/23824813/job/nv2g992b...

Well, that's interesting, and strange given that such a label does exist https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat....

Could it be something related to line endings and config.autocrlf?

Antony Polukhin

14 Apr 14 Apr

6:53 a.m.

On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost wrote:

...

Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

Rene Rivera

1:33 p.m.

On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin wrote:

...

On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost wrote:

...
Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

So... There's something weird in the Appveyor VS 2013 image that is not present in the VS 2015 or 2017 images. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Rene Rivera

1:40 p.m.

On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera wrote:

...

On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin wrote:

...
On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost wrote:

...
Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

So... There's something weird in the Appveyor VS 2013 image that is not present in the VS 2015 or 2017 images.

My suggestion would be to switch all those 2013 images to the 2015 images. It has all the same versions of compilers. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Andrey Semashev

5:28 p.m.

On 4/14/19 4:40 PM, Rene Rivera via Boost wrote:

...

On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera wrote:

...
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin wrote:

...
On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost wrote:

...
Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

So... There's something weird in the Appveyor VS 2013 image that is not present in the VS 2015 or 2017 images.

My suggestion would be to switch all those 2013 images to the 2015 images. It has all the same versions of compilers.

Tried this with Boost.WinAPI and it seems to have worked. Thanks!

Antony Polukhin

6:01 p.m.

On Sun, Apr 14, 2019, 16:40 Rene Rivera wrote:

...

On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera wrote:

...
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin wrote:

...
On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost wrote:

...
Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

So... There's something weird in the Appveyor VS 2013 image that is not present in the VS 2015 or 2017 images.

My suggestion would be to switch all those 2013 images to the 2015 images. It has all the same versions of compilers.

This may work, however having an unknown issue in the b2 code makes me nervous. This issue could fire on a user device at some inappropriate time (during release candidate testing for example).

...

Rene Rivera

6:13 p.m.

On Sun, Apr 14, 2019 at 1:02 PM Antony Polukhin wrote:

...

On Sun, Apr 14, 2019, 16:40 Rene Rivera wrote:

...
On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera wrote:

...
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin wrote:

...
On Sat, Apr 13, 2019, 23:17 Rene Rivera via Boost < boost@lists.boost.org> wrote:

...
Well, that's interesting, and strange given that such a label does exist <

https://github.com/boostorg/build/blob/develop/src/engine/config_toolset.bat...

Same issue with variant. Note that there's one successful build https://ci.appveyor.com/project/apolukhin/variant-ykfti/builds/23831018 . Comparing the environments of failed and succeeded builds may be helpful in locating the issue.

So... There's something weird in the Appveyor VS 2013 image that is not present in the VS 2015 or 2017 images.

My suggestion would be to switch all those 2013 images to the 2015 images. It has all the same versions of compilers.

This may work, however having an unknown issue in the b2 code makes me nervous. This issue could fire on a user device at some inappropriate time (during release candidate testing for example).

It's unpractical to test the unbounded interactions from bad user configurations. And since the toolsets themselves have no problems < https://dev.azure.com/grafikrobot/B2/_build/results?buildId=50> I don't see the advantage of trying to debug the Appveyor setup. If someone runs into a problem in their system then we can debug it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2143

Age (days ago)

2144

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Andrey Semashev
Antony Polukhin
Peter Dimov
Rene Rivera