boostorg / boost-ci Goto Github PK
View Code? Open in Web Editor NEWContinuous Integration Toolkit for boostorg code repositories
License: Boost Software License 1.0
Continuous Integration Toolkit for boostorg code repositories
License: Boost Software License 1.0
The installation takes time and fails often (https://travis-ci.org/boostorg/signals2/jobs/542405347), and nobody seems to be using it; we have UBSAN, valgrind, and Coverity Scan on the builds. I think we should disable the cppcheck build and update the template to remove it as a job.
On AzP OSX image the enforce script still tries to read /proc/cpuinfo leading to:
cat: /proc/cpuinfo: No such file or directory
+++ cpus=' 0'
+++ export B2_JOBS=1
+++ B2_JOBS=1
We should at least add a fallback like sysctl -n hw.ncpu
or very fancy python -c 'import multiprocessing as mp; print(mp.cpu_count())'
(from https://stackoverflow.com/questions/1715580/how-to-discover-number-of-logical-cores-on-mac-os-x)
The SHASUM of the codecov executable fails SHASUM check in GHA but not locally and apparently not in appveyor, so I am confused.
I added as no-cache... I suspect it is getting cached somewhere, and the cache is ignoring pragma no-cache, or there's something else going on.
https://github.com/boostorg/boost-ci/runs/5093231630?check_suite_focus=true#step:7:172
I'd like to change the coverage collecting a bit and want some feedback @mloskot @pdimov if you like
Coverage is a 3 step process:
Some libraries have different configurations that they want to test. So I already split that process into 2 steps (prior all 3 was one script call) into "collect" (step 1&2) and "upload" (step 3) to be able to run collect multiple times before uploading.
I think this is still an issue. Now we have to duplicate the collect step and the regular build step. Because obviously the different configurations should be tested for coverage and non-coverage builds. I.e. the coverage build step should be the same as the regular build step. So we should only have
I.e. change
boost-ci/.github/workflows/ci.yml
Lines 165 to 171 in f19a988
Note: Actually this https://github.com/boostorg/nowide/blob/5c762e889ad08bcc15a2c8000a38ffe9a1e8cc9c/.github/workflows/posix.yml#L93-L97 should not be conditioned on coverage...
So basically: codecov.sh
should NOT call build.sh
but simply set up the env vars/flags so the regular build.sh
can be used, i.e. this:
boost-ci/.github/workflows/ci.yml
Lines 165 to 167 in f19a988
To be backwards compatible: The travis codecov.sh
(only one we had so far) can simply call the main codecov.sh with setup and then do the build but in the template CI scripts we do it "properly"
Today the travis yaml file has to be copied from a template in this repository into a file in every repository that wants to use it. A bunch of the content is boilerplate and can now be delivered by versioning this repository and using their Shared Build feature, allowing parts of travis.yml to be imported.
The net effect of rolling this out is that updates to some travis functionality can be done quickly through a version bump in a consuming repository's travis yaml, or if the consuming repository wants to make it automatic they could pull a "latest" tag that we maintain and roll forward.
In the end someone does have to make a change on each repository. Teaching dependabot to attempt automatic updates to these import versions would be great but since GitHub acquired DependaBot, it's unlikely they would do anything to support Travis.
Why some of MSVC jobs specify both address-model
-s, i.e. 32 and 64, e.g.
boost-ci/templates/appveyor.yml
Lines 73 to 75 in ceb7055
while other only 64
boost-ci/templates/appveyor.yml
Lines 66 to 68 in ceb7055
I found that multi-address-model
jobs on Windows are tricky to handle if a library tests need external dependencies installed with vcpkg or conan. For example, this command does not allow to point to vcpkg-installed dependencies for both targets:
b2 address-model=64,32 include=%VCPKG_INC% library-path=%VCPKG_LIB%
Would it be sensible to run single address-model
per build job by default? What are pros/cons?
Currently, AzP configuration is based on macos-10.13 and Xcode 8.x through 10.x
Apparently, AzP offers macOS 10.14 with multiple Xcode 11.x versions, but there are no Xcode 8.x and earlier 9.x
https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/macos/macos-10.14-Readme.md
It may be a good idea to cover both macOS 10.13 and 10.14 with full coverage of Xcode versions.
Consider
git clone --depth 1 https://github.com/boostorg/boost-ci.git C:\boost-ci
I think this also works in the yml
clone_depth: 1
Suggest we limit the number of cxxstd per build job to 2, except for some of the special build jobs (like ubsan). I have this set up in a uuid dry-run pr on my fork:
Suggest we limit the variant to debug except for a couple jobs where we build release. Most projects do not have debug vs. release specific preprocessor branches, and release build optimization is expensive. Given all the other checks and balances we have, this will reduce the burden on the CI providers and get builds through faster, which everyone will enjoy.
Shall we remove the Travis CI scripts from this repo?
It looks like none of the Boost repositories have used Travis recently
https://app.travis-ci.com/github/boostorg
Currently the mingw builds on AppVeyor are failing. The reason is that the package manager tries to download old images which seem no longer available (cf. below or https://ci.appveyor.com/project/tobias-loew/unordered/builds/39210079/job/pon5fdeju46656t9)
E.g. the oldest version on http://repo.msys2.org/mingw/x86_64/ is mingw-w64-x86_64-icu-66.1-1-any.
Can we do anything about it?
C:\boost-root>FOR %a IN ("gcc" "icu" "libiconv" "openssl" "xz" "zlib") DO (c:\msys64\usr\bin\env MSYSTEM=MINGW32 c:\msys64\usr\bin\bash -l -c "pacman --sync --needed --noconfirm mingw32/mingw-w64-i686-%a" || EXIT /B 1 )
C:\boost-root>(c:\msys64\usr\bin\env MSYSTEM=MINGW32 c:\msys64\usr\bin\bash -l -c "pacman --sync --needed --noconfirm mingw32/mingw-w64-i686-"gcc"" || EXIT /B 1 )
warning: mingw-w64-i686-gcc-9.1.0-3 is up to date -- skipping
there is nothing to do
C:\boost-root>(c:\msys64\usr\bin\env MSYSTEM=MINGW32 c:\msys64\usr\bin\bash -l -c "pacman --sync --needed --noconfirm mingw32/mingw-w64-i686-"icu"" || EXIT /B 1 )
resolving dependencies...
looking for conflicting packages...
Packages (1) mingw-w64-i686-icu-64.2-1
Total Download Size: 17.45 MiB
Total Installed Size: 93.00 MiB
:: Proceed with installation? [Y/n] warning: no /var/cache/pacman/pkg/ cache exists, creating...
:: Retrieving packages...
error: failed retrieving file 'mingw-w64-i686-icu-64.2-1-any.pkg.tar.xz' from repo.msys2.org : The requested URL returned error: 404
error: failed retrieving file 'mingw-w64-i686-icu-64.2-1-any.pkg.tar.xz' from sourceforge.net : The requested URL returned error: 404
error: failed retrieving file 'mingw-w64-i686-icu-64.2-1-any.pkg.tar.xz' from www2.futureware.at : The requested URL returned error: 404
error: failed retrieving file 'mingw-w64-i686-icu-64.2-1-any.pkg.tar.xz' from mirror.yandex.ru : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
C:\boost-root\libs\unordered>set lastexitcode=1
C:\boost-root\libs\unordered>set 1>C:\Users\appveyor\AppData\Local\Temp\1\tmp6BA.tmp
C:\boost-root\libs\unordered>echo C:\boost-root\libs\unordered 1>C:\Users\appveyor\AppData\Local\Temp\1\tmp6BB.tmp
C:\boost-root\libs\unordered>exit /b 1
Command exited with code 1
@sdarwin What is the purpose of https://github.com/boostorg/boost-ci/blob/master/.drone/drone.sh ?
The drone config does a load("@boost_ci//ci/drone/:functions.star", "linux_cxx","windows_cxx","osx_cxx","freebsd_cxx")
so IMO requiring library authors to add the .drone
folder provides no value, does it?
Apparently there are changes to e.g. libiconv in recent MacOs and/or xcode. See e.g. boostorg/locale#206
So I'd like to at least have CI for those.
Is this possible for Drone?
The readme says:
Copy the .drone.star file and .drone directory from this repository to the top level of your repository.
So what will happen is that e.g. linux_cxx
will Pull down Boost.CI:
boost-ci/ci/drone/functions.star
Line 61 in 4ed2aa3
And the current example drone file will do that again:
Line 21 in 4ed2aa3
So this duplicates work wasting resources.
Furthermore the Drone config is much less readable than e.g. the Github config
@sdarwin Could you work on the first part, i.e. that it downloads Boost.CI at most once and only if not running on Boost.CI? I don't understand why we would need .drone/boost-ci
and ci
when having the latter is enough (see e.g. Github actions)
I started work on an improved drone config in a branch
I just configured my project to use AppVeyor:
https://github.com/lpranam/astronomy/blob/CI/appveyor.yml
I encountered this bug:
https://ci.appveyor.com/project/lpranam/astronomy/builds/25792430/job/1r5xckyfoe6090g7
It prompts the message in the console and then it has to wait for infinite time as no input cannot be given and ultimately job fails due to the time limit.
I am not sure if I am doing anything wrong or it is indeed a bug. I am not much familiar CIs.
If UBSAN_OPTIONS isn't set, it should be set to print_stacktrace=1
in build.sh. This avoids the current inconsistency in .travis.yml and is usually (always?) what is wanted
The self-updating of B2_...-variables in build.bat and enforce.sh leads to problems when e.g. B2_CXXFLAGS is defined in the drone.star "matrix". Then B2_CXXFLAGS gets updated twice:
in drone.star: 'B2_CXXFLAGS': '-Wno-variadic-macros'
2.script run:
B2_CXXFLAGS=cxxflags=cxxflags=-Wno-variadic-macros
We need someone with access to the coverity project of boost-ci to add the details (token and email) to Drone to fix the failure.
This went unnoticed so far due to a bug which made the script never execute that i just fixed.
But no idea who the admin there is that can grant access.
We should consider tagging and/or releasing boost-ci. When someone integrates with boost-ci they can pull it using a stable tag that will never change. That way changes we make to boost-ci will not break numbers of repositories. Thoughts?
The names (keys) in the jobs.matrix entries are invalid:
Matrix configuration names must contain only basic Latin alphabet letters (A-Z and a-z), digits (0-9), and underscores (_). They must start with a letter. Also, their length must be 100 characters or fewer.
We should replace the spaces by underscores
Travis supports compiler: foobar
as a key for jobs and sets TRAVIS_COMPILER
to that
I suggest:
echo "using $B2_TOOLSET : : $TRAVIS_COMPILER ;" > ~/user-config.jam
Note: TRAVIS_COMPILER may be /usr/bin/clang++
. In that case B2_TOOLSET
must be set to clang
. Similar for clang++-3.3
--> clang-3.3
My current code:
if [[ "$TRAVIS_COMPILER" =~ clang ]]; then
export B2_TOOLSET=clang
elif [[ "$TRAVIS_COMPILER" =~ g\+\+ ]]; then
export B2_TOOLSET=gcc
else
false
fi
This def1aee did this:
- - B2_TOOLSET=gcc-7
+ - B2_TOOLSET=03,11
+ - B2_TOOLSET=gcc-8
but wasn't it supposed to do this?
- - B2_TOOLSET=gcc-7
+ - B2_CXXSTD=03,11
+ - B2_TOOLSET=gcc-8
To make using the CI as easy as possible the common Boost build / Boost library test should be made as simple as possible.
E.g. I created a function which can be used as job(compiler='clang-3.5', cxxstd='11', os='ubuntu-16.04'),
similar to the GithubActions config
What we need to do is:
common_install.sh
)build.sh
)The first step is currently done by linux-cxx-install.sh
due to not having enough space to do it in the Drone config file as on GHA.
The other 3 steps are wrapped in the drone.sh
script.
This is already nice as Boost authors (with #186) only need to copy the drone.star file and adjust that for the "basic" workflow.
However e.g. for Boost.Locale I need only a slightly different install process: I need to install/setup some system locales for Linux
For GHA this is easy as I can simply add a new step into the config. For Drone I would need to copy and modify the linux-cxx-install.sh
script and hence keep (at least) 2 files up to date (the star-file and the install-script)
Hence what I'd rather like to do is have a custom install script for drone which is run in addition to the default.
Ideas:
linux-cxx-install-pre.sh
/linux-cxx-install-post.sh
@sdarwin thoughts?
Travis supports also Ubuntu 20.04, see https://docs.travis-ci.com/user/reference/focal/ which seems to be not part of travis.yml yet
See microsoft/azure-pipelines-agent#1631
Test expression is e.g., ++ '[' azp-outdated-images == master ']'
rather than fix/azp-outdated-images
so if I do a PR with a /
in it and it is fix/master
it'll not do what we want ^^
From
boost-ci/ci/azure-pipelines/install.sh
Line 62 in 8b32c09
They claim that there is nothing to fix, suggestion microsoft/azure-pipelines-agent#1631 (comment) is to use the full one and remove refs/heads
from the front (or in this case could also check if it is refs/head/master
).
Low priority, couple of ways to fix, wanted to raise issue but won't fix until the other one is done.
Looks like the ccache action doesn't actually save the cache. This is from the post-step:
Cache hit occurred on the primary key ubuntu-20.04--gcc-11, not saving cache.
So it doesn't update the cache! O.o
We could use a dedicated ccache action like https://github.com/hendrikmuhs/ccache-action which handles the key-creation etc. for us or do it manually (see fix_ccache
branch which I'm testing right now)
I've been experiencing some strange behaviors on the xenial distributions in travis when building with gcc 4.8 and 4.9. The root cause is that the libstdc++6 library comes from gcc 5.4.0 on this distribution using the newer dual ABI, therefore one cannot build with gcc 4.8 or 4.9 and expect to get a good result. For example in the date_time unit tests for input facets, the code catches std::ios_base::failure, however this was not happening. With some debugging, I found what's being thrown is a std::ios_base::failure[cxx11] instead.
The fix is likely to change any 03 jobs to use trusty instead of xenial.
We currently have compiler versions sorted ascending on GHA and descending on Azure.
We should decide for one scheme and change one or the other file especially with the new syntax which allows to remove redundant jobs from either one.
Question: Which one do you prefer? Ascending for me.
We test with MinGW and Cygwin but not with MSYS2.
I'm not really sure about the difference of MinGW vs MSYS2 MinGW (maybe someone can help here?) but might be worth adding. Especially as it seems that the MSYS2 MinGW environment has e.g. GCC 11 and I have a bugreport which sounds like this environment was used with (some?) Boost libraries.
At the end of March 2020.
In Boost.unordered and Boost.Locale I see failures after using the updated compilers from a60085a
E.g.: https://github.com/boostorg/locale/runs/6744070853?check_suite_focus=true
==21529==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new vs free) on 0x60b0000016f0
#0 0x55f6f62020c2 in free (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0x1320c2) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5)
#1 0x7f9a9707624d in std::range_error::~range_error() (/lib/x86_64-linux-gnu/libc++abi.so.1+0x2424d) (BuildId: 92148758f185dd2a38d85fe5fe008fe28543e10c)
#2 0x7f9a97078553 in __cxa_end_catch (/lib/x86_64-linux-gnu/libc++abi.so.1+0x26553) (BuildId: 92148758f185dd2a38d85fe5fe008fe28543e10c)
#3 0x55f6f623f892 in has_std_locale(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0x16f892) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5)
#4 0x55f6f62405d4 in main (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0x1705d4) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5)
#5 0x7f9a96d4ad8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 89c3cb85f9e55046776471fed05ec441581d1969)
#6 0x7f9a96d4ae3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 89c3cb85f9e55046776471fed05ec441581d1969)
#7 0x55f6f617f524 in _start (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0xaf524) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5)
0x60b0000016f0 is located 0 bytes inside of 101-byte region [0x60b0000016f0,0x60b000001755)
allocated by thread T0 here:
#0 0x55f6f623d13d in operator new(unsigned long) (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0x16d13d) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5)
#1 0x7f9a970e1f6e in std::runtime_error::runtime_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (/lib/x86_64-linux-gnu/libc++.so.1+0x4ef6e) (BuildId: b21b5b84d38618ac5758baefbe063160913da4cb)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/home/runner/work/locale/boost-root/bin.v2/libs/locale/test/test_std_formatting.test/clang-linux-14/release/address-sanitizer-norecover/cxxstd-20-iso/link-static/stdlib-libc++/threading-multi/undefined-sanitizer-norecover/visibility-hidden/test_std_formatting+0x1320c2) (BuildId: 4876f9a0c6647775b7d8244ddeeca2157e74a2e5) in free
==21529==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==21529==ABORTING
I.e. the culprit is this job:
boost-ci/.github/workflows/ci.yml
Lines 86 to 87 in 699bb3b
We could handle that by NOT using libc++, but we have GCC 12 with libstdc++ and sanitizers already at
boost-ci/.github/workflows/ci.yml
Lines 59 to 60 in 699bb3b
Or revert back to Clang 12 like it was at
boost-ci/.github/workflows/ci.yml
Lines 83 to 84 in 76211c3
@pdimov Any preference?
I have trouble with FreeBSD on Drone and would need a hand:
job(compiler='clang-10', cxxstd='11,14,17,20', os='freebsd-13.1')
works but throws warnings for system headers in /usr/local
job(compiler='clang-15', cxxstd='11,14,17,20', os='freebsd-13.1')
fails at runtime with Undefined symbol "_ZTIDu"
job(compiler='gcc-11', cxxstd='11,14,17,20', os='freebsd-13.1', linkflags='-Wl,-rpath=/usr/local/lib/gcc11')
fails at runtime with a seg faultAny idea how to solve or even approach this without a local FreeBSD?
Currently boost-ci copies the codecov.yml contained at https://github.com/boostorg/boost-ci/blob/master/.codecov.yml to the repo root. That has multiple problems:
It is documented that the file must not be named .codecov.yml
: https://docs.codecov.io/docs/codecov-yaml#section-can-i-name-the-file-codecov-yml. However the bash uploader does kinda work because it does git ls-files "*codecov.yml" "*codecov.yaml"
. But due to the second problem this might not be enough.
The file currently contains fixes
, but those are used server-side not client side. The bash upload simple pass the LOCATION of the yaml file to the uploaded file :
# Append git file list
# write discovered yaml location
echo "$yaml" >> $upload_file
--> We can get rid of that file as it seems to work nonetheless
I tried Boost.CI on Boost.Locale where a test binary links against Boost::locale
which privately links against Boost::thread
.
This fails on some platforms, e.g. Ubuntu 20.04 as the Boost.Thread library cannot be found. See e.g. https://github.com/Flamefire/locale/runs/6047122561?check_suite_focus=true
/home/runner/work/locale/boost-root/libs/locale/test/cmake_test/build_cmake_install_test/main: error while loading shared libraries: libboost_thread.so.1.80.0: cannot open shared object file: No such file or directory
But the library is installed:
Installing: /home/runner/.local/lib/libboost_thread.so.1.80.0
Also on Windows the test also fails likely due to the same reason:
1/1 Test #1: main .............................Exit code 0xc0000135
***Exception: 0.01 sec
It looks like we'd need to add the library install path to LD_LIBRARY_PATH
on Linux and something similar on Windows (PATH
?) although I feel like this is something which should be handled by CMake but isn't.
Would be good if we could fix that "by default" in the Boost.CI samples.
@pdimov Any ideas?
When I update Boost.JSON to use the new .azure-pipelines.yml, I get failures:
https://vinniefalco.visualstudio.com/json/_build/results?buildId=769&view=logs&j=eaa15c43-7f79-57f7-ec56-5d5933cacfc8&t=cb081657-b69e-52d4-18c8-e97eff82a2e9&l=28
The older template works:
https://github.com/vinniefalco/json/blob/4c03bec97c57e895b9d0582f3f34ea3308a1243f/.azure-pipelines.yml
There are multiple ways to add AWS-hosted runners to boostorg/boost-ci.
or
or
In the meantime anyone is welcome to experiment with the self-hosted runners https://github.com/cppalliance/githubactions however the config will need to be modified.
FYI - when testing against the master branch of lcov.
The new lcov flag --ignore-errors unused
was needed, including in codecov.sh.
An apt package libcapture-tiny-perl
was required.
The apt packages libdatetime-perl libdatetime-format-dateparse-perl
were required, if running genhtml.
There are new features in lcov. To be able to use the master branch now, I wonder if both the version and the command line flags of lcov should be adjustable via variables in codecov.sh.
Can we please avoid these repetitions of name and flag? I guess we need a new B2_FLAGS
to pass arbitrary flags as e.g. currently B2_CXXFLAGS is abused to pass flags to b2 like ASAN.
@pdimov uses ${LINKFLAGS:+linkflags=$LINKFLAGS}
and ${VISIBILITY:+visibility=$VISIBILITY}
which I find pretty neat :)
Last week, I started integrating the new boost-ci with boost.unordered.
At that point, boost.unordered's tests were mostly failing and for that reason there hadn't been a PR for the new drone-ci. So, I started out on my own fork of boost.unordered and Sam Darwin enabled my account to run tests with drone. Here's a short protocol of what I did and how it worked out:
Summary:
boost-ci integrates seamless with other boost projects and works out of the box. The upcoming problems originated from the CI-platforms (Travis refusing, Appveyor cannot install MinGW) and the failing tests in the boost-project (buggy compilers / test-code).
Travis added a s390x architecture target in November 2019 which allows for big-endian testing, eliminating the need for multiarch docker container testing. The example should be updated.
On Windows, it is not uncommon Boost tests builds fail with error failed to write output file, e.g.
failed to write output file
'bin.v2\libs\gil\test\extension\dynamic_image\h-extension-dynamic_image-image_view_factory.test\msvc-14.2\release\address-model-64\asynch-exceptions-on\cxxstd-latest-iso\threading-multi\h-extension-dynamic_image-image_view_factory.obj.rsp'
!
Question: would it be sensible to run b2
with --abbreviate-paths
by default on all Windows jobs?
Check https://dev.azure.com/boostorg/boost-ci/_build/results?buildId=1511&view=logs&j=288c7346-de5f-5112-54bc-d1c2ae665540&t=528f5383-0ab2-5f0a-4b8f-7e7b11d5464f
The clang 3.7 build has some issues which make Boost.CI fallback to clang++
which then uses the system clang 9!
Trying to find out where that clang is
Output:
++ command -v clang++-3.7
++ echo 'WARNING: Compiler clang++-3.7 was not installed properly'
WARNING: Compiler clang++-3.7 was not installed properly
+++ command -v clang++-3.7
++ echo 'using clang : : : ;'
Let's say you are building mingw on windows with gcc; that job currently uses msvc to build the bootstrap in CI (though #137 resolves it, there are more things we need to do...).
Similarly you might have gcc and clang installed, however boost build is built with gcc in clang jobs!
See: https://github.com/boostorg/boost-ci/runs/5071619375?check_suite_focus=true
Another one is mingw; you can specify mingw to bootstrap but not to b2.
We need the bootstrap to take an argument for the toolset. Now here's one of the problems. The definition of TOOLSET that we pass to boost build is not recognized by bootstrap (from an Azure Devops job):
D:\a\1\boost-root>cmd /c bootstrap msvc-14.3
Building Boost.Build engine
###
### "Unknown toolset: msvc-14.3"
###
### You can specify the toolset as the argument, i.e.:
### .\build.bat msvc
###
### Toolsets supported by this script are: borland, como, gcc,
### gcc-nocygwin, intel-win32, mingw,
### vc12, vc14, vc141, vc142, vc143
###
### If you have Visual Studio 2017 installed you will need to either update
### the Visual Studio 2017 installer or run from VS 2017 Command Prompt
### as we where unable to detect your toolset installation.
###
Any objections to enable the Discussions for asking questions, discussing stuff or you'd rather prefer Issues for 'end-user' questions?
Are there plans to add support for CI builds via github actions? Should be similar to the azure pipeline yml, see https://github.com/actions/virtual-environments
The scripts perform "b2 ." which requires a root Jamfile. Instead, it should perform "b2 test". Root Jamfiles should not be required to use boost-ci.
I encountered this when I was testing my fork of dynamic_bitset. My fork wasn't glenfe/dynamic_bitset, but instead glenfe/boost.dynamic_bitset.
Users may fork a Boost library into a repository name that isn't the same as the Boost library name. The Travis and Appveyor scripts you provide should not make the contrary assumption.
Boost libraries like core, smart_ptr, align, etc. that do not use boost-ci for Travis and Appveyor do not suffer from this problem.
This is a trivial 'feature' request I'd like to propose.
Would it be acceptable to 'hide' the non-essential and redundant, for reader of the build matrix on AppVeyor, tag APPVEYOR_BUILD_WORKER_IMAGE
and bring the more important build properties to the front?
To turn this
- FLAVOR: Visual Studio 2017 C++2a Strict
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
B2_ADDRESS_MODEL: address-model=64
B2_CXXFLAGS: cxxflags=-permissive-
B2_CXXSTD: latest # 2a
B2_TOOLSET: msvc-14.1
into this:
- FLAVOR: Visual Studio 2017 C++2a Strict
B2_ADDRESS_MODEL: address-model=64
B2_CXXFLAGS: cxxflags=-permissive-
B2_CXXSTD: latest # 2a
B2_TOOLSET: msvc-14.1
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
for all the matrix jobs.
Boost.Build now provides common features for the sanitizers:
boostorg/build#409
Shall we switch the COMMENT=ubsan
to use those?
Second, I'd suggest to split the single COMMENT=ubsan
job into job per sanitizer type (undefined, nullability, integer).
For example, in Boost.GIL, the two first pass but the -fsanitize=integer
failed.
The CMake tests assume that $SELF/test/cmake_subdir_test and $SELF/test/cmake_install_test are present in the repo and have the right CMakeLists.txt in them, like in https://github.com/boostorg/variant2.
Please add a note to installation instructions here in the README that one has to adapt the CMake builds when porting to boost-ci.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.