New B2 version, and CI failures.
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
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...
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
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#L57>.
Could it be something related to line endings and config.autocrlf?
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.
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin <antoshkka@gmail.com> 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. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin <antoshkka@gmail.com> 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. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 4/14/19 4:40 PM, Rene Rivera via Boost wrote:
On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin <antoshkka@gmail.com> 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.
Tried this with Boost.WinAPI and it seems to have worked. Thanks!
On Sun, Apr 14, 2019, 16:40 Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin <antoshkka@gmail.com> 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).
On Sun, Apr 14, 2019 at 1:02 PM Antony Polukhin <antoshkka@gmail.com> wrote:
On Sun, Apr 14, 2019, 16:40 Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 8:33 AM Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Apr 14, 2019 at 1:54 AM Antony Polukhin <antoshkka@gmail.com> 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
participants (4)
-
Andrey Semashev -
Antony Polukhin -
Peter Dimov -
Rene Rivera