| Age | Commit message (Collapse) | Author |
|---|
|
The "scripts" folder is quite cluttered, let's make it a bit better.
|
|
|
|
Unfortunately "sonar-scanner" fails with the following error:
ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:
* you are using the latest version of the build-wrapper and the SonarCFamily analyzer
* your compiler is supported
* you are wrapping your build correctly
* you are wrapping a full/clean build
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:239)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:82)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:403)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:399)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:362)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:98)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233)
at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123)
at org.sonarsource.scanner.cli.Main.execute(Main.java:77)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
The file is not generated because the C/C++ plugin library fails to load:
ERROR: ld.so: object '/home/travis/.sonar/cache/87f7532f0609a32b83c77be7ae487f14/build-wrapper-linux-x86/libinterceptor-${PLATFORM}.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
|
|
After switching from Ubuntu Xenial (16.04) to Ubuntu Cosmic (18.04), the following issue appeared:
cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: error: use -Winvalid-pch for more information
cc1plus: fatal error: release/mumble_pch.hpp: No such file or directory
This commit workarounds the issue by disabling PCH.
|
|
https://docs.travis-ci.com/user/reference/bionic
The ARM64 build was already using Bionic, even with "dist: xenial".
This commit also changes "https://dl.mumble.info/mirror/mirror.mxe.cc" with "https://dl.mumble.info/mirror/pkg.mxe.cc".
Originally only "mirror.mxe.cc" existed because we set up the mirror when https://pkg.mxe.cc was not reachable (we mirrored https://mirror.mxe.cc).
Once https://pkg.mxe.cc was back online, we mirrored it and symlinked "mirror.mxe.cc" to "pkg.mxe.cc".
|
|
Travis CI announced support for ARM64 builds a few days ago: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
We already have a Linux x86_64 build on Azure Pipelines, which also generates an AppImage.
This commit changes the architecture for the build we have on Travis CI, so that it's not redundant anymore (and becomes useful).
The "no-pch" build is not changed because the only differences consist in the PCH header not being used and the SonarQube Scanner being executed.
Also, we don't want to use an ARM64 builder unnecessarily.
|
|
The macOS build on Azure Pipelines was restored in 5094de66e05b4933c0edccf68fd42d5f9decfb55.
|
|
|
|
[skip azurepipelines]
|
|
|
|
|
|
Our MinGW build was left stale due to mumble-voip/mumble#3208.
Altough our current MinGW builders use Wine as their test runner
-- and were added to allow_failures exactly for that reason --
it makes more sense to get blocked from merging on build failures.
The alternative is that we actively *check* that the MinGW is not
broken, which doesn't happen in practice.
We obviously can't expect Wine to mirror the exact behavior on any
particular Windows version, but let's just look at the MinGW targets
in .travis.yml as a check for whether a) the MinGW build works on Linux,
and b) whether our tests pass using Wine.
|
|
|
|
This commit adds a Homebrew-based macOS build to our Travis CI build
matrix.
It also cleans up the exising build matrix such such that Linux builds
are built only on Linux hosts, and macOS builds are only built on macOS
hosts.
|
|
It's convenient to have a proof-build that checks whether
our no-pch build works, to keep it working.
|
|
|
|
|
|
|
|
Travis builds with Ubuntu 12.04 so this is more of a
legacy compilation test with qt4. Should still be
helpful.
|
