Web: Emscripten port updated to current tools. Add saving of options in local storage.
U Web: Emscripten port updated to current tools. Add saving of options in local storage.
Re-creating the edge release for every push
to master creates many superfluous release notifications.
Stop creating those releases and provide users with direct
links to the workflow artifacts instead via the
nightly.link GitHub app (https://github.com/apps/nightly-link).
Fixes#1103
The snaps use git describe to determine
their grade (stable/devel). Fetch the tags to
make this possible.
Point users to the official release in the stable channel in README.md.
Travis's move away from providing unlimited build time to OSS and its
inferior developer experience are the reason for this change.
The workflows are simple and straightforward, and the build scripts
are mostly 1:1 the same we used on Travis. This avoids vendor lock-in
as much as possible in case we need to move somewhere else in the future.
We introduce two workflows:
1. CD (cd.yml)
Runs on: Commits to master, GitHub releases.
Does: Run tests, build release assets, update GitHub edge release or
release to developer created GitHub release. Builds & uploads snaps to
the Snap Store.
2. Test (test.yml)
Runs on: Every commit except those on master and v* tagged ones.
I.e. PRs and other branches.
Does: Run tests only.
Creating a release is now an explicit operation. On the Travis workflow,
pushing a tag that begins with "v" will lead to the automatic creation of
an associated GitHub release.
On GHA, creating a GitHub release by hand will trigger the CD-workflow
to build & upload the release assets.
Other differences to Travis:
- Windows builds on Visual Studio 16 2019 instead of Visual Studio 15 2017.
- Snap builds run in docker containers, not directly on the build host.
- Snap arm64 builds on amd64 via QEMU user emulation.
This is slower than what Travis gave us and should be changed when/if
GHA offers ARM64 build runners.
- GHA retains build artifacts for 90 days by default.
Required secrets:
- MACOS_CERTIFICATE_PASSWORD
- MACOS_CERTIFICATE_P12
- MACOS_APPSTORE_APP_PASSWORD
- MACOS_APPSTORE_USERNAME
- MACOS_DEVELOPER_ID
- SNAPSTORE_LOGIN
Discussion: https://github.com/solvespace/solvespace/issues/807
PR: https://github.com/solvespace/solvespace/pull/824Fixes#807
It was added in 3a3a2755b as a potential way to export colorful meshes
to Horizon EDA but ended up being supported only by SolveSpace. Since no
software can consume the exported q3do files the feature is superfluous.
See https://github.com/solvespace/solvespace/issues/795 for details.
VS2013 does not have constexpr support and in general is quite buggy.
There's no reason to use it anymore as even XP toolsets are available
for VS2015 and VS2017.
Not everyone knows how to check out the sources with git (or that
we require that, because of submodules), and has the basic build
tools like gcc installed, so point that out explicitly.
It's a deprecated platform that has weird OpenGL-related bugs and
is incompatible with using EGL anyway. It was clear we're going
to drop it, the only question was when. Answer: now.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.