With GOARCH=386, we can't readily build packages that use Cgo. However,
we already have the Android SDK available, so use that to test for 32-bit
issues such as #384.
References: https://todo.sr.ht/~eliasnaur/gio/384
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit runs Gio's test harness in 32-bit mode as well as 64-bit. This helps
catch bugs in Gio and its dependencies where integer overflow causes build or
runtime problems.
The complexities of cross-compiling CGO made it prohibitively difficult to test
all of Gio, so these changes only run tests for packages in pure Go.
References: https://todo.sr.ht/~eliasnaur/gio/384
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Running GPU tests on freeBSD currently fails with
vulkan: vkCreateGraphicsPipelines: error -8
Disable Vulkan by removing the vulkan-loader package.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
For some reason, the Mesa OpenGL software renderer fails to correctly
render some of the tests in gpu/internal/rendertest. The Linux builder
uses the Vulkan software renderer, so only the FreeBSD builders fails.
The root cause may be a Gio issue, but since all the other backends work,
including hardware OpenGL, there is a likelyhood the issue is in Mesa.
I don't have the temperament to debug Mesa issues, so this change disables
software OpenGL on FreeBSD, which will cause the rendertests to skip.
Running Vulkan tests under FreeBSD is blocked on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257303
In practice it won't matter: FreeBSD and Linux use the same software
for software renderers.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change implements a Vulkan port for the two renderers, old and
compute. Run with GIORENDERER=forcecompute to test the compute renderer.
To shake out bugs faster, it is also made the default on systems that
support it. To disable Vulkan and force the use of OpenGL, use the
`novulkan` tag:
$ go run -tags novulkan gioui.org/example/kitchen
Don't forget to file an issue describing the issue that prompted the use
of the tag.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
EGL_PLATFORM=surfaceless allows rendering tests to complete in headless
mode. However, the headless chrome tests fail with that setting. Change
the linux builder to only set the variable when needed.
Enable verbose output of tests while here. We can keep an eye on skipped
tests that way.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A recent change to the native toolchain or system on the builder infrastructure
made the arguments for the apple cross compiler needed always, not just in
CGO_CFLAGS and CGO_LDFLAGS.
Remove them altogether and rely on a recent change to the giouiorg repository
for including them in the clang-ios and clang-macos wrappers.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The example module is moving to git.sr.ht/~eliasnaur/gio-example.
We still need some main package for testing gogio, so update reference
to use the module path (gioui.org/example).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As suggested by Chris Waldon, this will catch pushes to master and
also during automatic testing of patches sent to the mailing list.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The python package is gone, we may not need it and/or Debian installs
python3 by default.
curl is needed for automatically applying patches from the mailing list.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A simple 'go test -modfile=<path>' won't work properly for the
end-to-end tests, since they run 'go build' under the hood as well.
To properly propagate the flag, we need to use GOFLAGS. Since -modfile
is always relative to the current directory, we can't use it to test
many packages at once, nor can we use it via 'go test ./gogio'.
While at it, document this distinction in go.local.mod to prevent others
getting confused like I did.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
It's essentially a copy of go.mod, but with the gioui.org module replaed
with the parent directory. Useful when wanting to try a change in the
root module as part of a gogio invocation or end-to-end test, such as
either of the following:
$ cd cmd; go test -modfile=go.local.mod ./...
$ cd cmd/gogio; go build -modfile=../go.local.mod
Since go.sum can essentially be shared, and since it seems to work with
the go tool, use a symlink. The way the -modfile flag works, if given
foo.mod, it will use the sum file at foo.sum. The only caveat is that
'go mod tidy -modfile=go.mod.local' will try to remove gioui.org lines,
since that module is replaced. So tidy shouldn't be used with -modfile.
In the future, the only upkeep needed for go.local.mod is to update the
external dependencies to mirror changes in go.mod. This is not automated
nor checked by CI, but it could be in the future if it becomes
repetitive or error-prone.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Installing it on Debian was enough, with the only wrinkle that
propagating -race won't work when we're cross-compiling, since
cross-compilation disables CGo by default.
For now, just skip the test in that edge case. If we want to use the
race detector on Windows in the future, we need to get a Windows CI
builder somehow.
Tested on my fork; see https://builds.sr.ht/~mvdan/job/164899.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
First, move from debian unstable to testing, since sway was promoted to
testing as of earlier this week.
Second, use the --sync option when using xdotool to move an X11 mouse.
This makes the command block until the mouse has finished moving to the
specified location, removing a potential race with the following
'xdotool click' command.
Third, deduplicate some logic into driverBase: tempDir to create a
temporary directory within a test, and needPrograms to skip a test if
the required programs aren't available.
Lastly, split the code that starts the X11 server into a method, so that
the future Wine e2e driver can reuse it. Since Wine is tightly coupled
with X11, we can reuse a good part of the code, including the X11 server
and the xdotool mechanisms.
We also add a TODO to perhaps improve the handling of the app's output
under each of the e2e test cases.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
It passes now, thanks to the recent work to add retries to screenshots.
If it turns out to still not be reliable enough, we can look at this
again.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
On Linux and FreeBSD, this means we no longer need to install Go twice,
since we don't need to bootstrap a Go build. This reduces the "install
go" step by over half a minute, and avoids installing a number of distro
packages.
Debian requires the pkg-config package to be explicit, as it's not part
of the build-essential metapackage, and we need it. It was being pulled
as a dependency from the golang package before.
OpenBSD is nearly the same change, modulo the fact that Go doesn't have
a binary release for it. So instead, we keep installing Go via the
system's package, and we download and build a source archive.
Finally, switch from Debian testing+experimental to simply unstable.
Sway 1.4 finally hit unstable a few days ago, and experimental is
extremely unstable, so this is a step in the right direction. Add a TODO
about going to just testing once sway 1.4 arrives there.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Elias Naur