Introductions - Who are you, and what are you building with UNA?

Getting Started
16

Late to this thread, but your Linux work is the reason I have anything running at all, so thank you, and I would like to offer something back.

My machine is ARM64 (WSL2 on Windows on ARM), which the Linux path does not quite reach. The vendored TouchGFX Linux libraries are x86-64 only and the framework core ships as binary objects, so there is no native build. I ended up running the simulator and the ARM firmware build in amd64 Docker containers under QEMU. It works, and the emulated build of Waypoint came out byte identical to UNA’s CI artifact apart from the version field and CRC, but it is slow, and two things bite:

  • QEMU cannot run x86-64 Ruby, so textconvert and videoconvert die. Since every project commits its generated/ output, a guarded shim that asserts the committed files exist gets past it, at the cost of not being able to regenerate text or fonts locally at all.
  • The same QEMU issue breaks python3-full’s postinst, which is why I install just python3-pip rather than following apps-ci.yml exactly.

Which brings me to the offer. I noticed your fix(cmake): make builds independent of where the SDK and app are checked out and the CI job asserting an app builds identically from two directories. I kept my app outside the SDK checkout and can confirm the CMake side holds up: it built first time with no path changes. The simulator side is still fixed depth, though, and I had to patch each of these by hand:

  1. config/gcc/app.mk, where touchgfx_path goes six levels up
  2. config/msvs/Application.props, where TouchGFXReleasePath goes eight levels up
  3. the mock filesystem sandbox, five levels up plus /Output, which silently sends AppConfig to the wrong directory and falls back to defaults
  4. simulator/gcc/Makefile and the .vcxproj do not glob, so a new .cpp links fine as firmware and fails only in the simulator

I would be glad to put a PR together extending your two directory CI assertion to the simulator build, if that is a direction you think would be accepted. I could also add a short note to Simulator.md along the lines of “ARM64 hosts: use the Windows simulator or an amd64 container, and here is why”. The first symptom is a thoroughly misleading imageconvert.out: 1: Syntax error: "(" unexpected, which is really ENOEXEC, and it cost me a while to work out.

One question, since you have built one of everything: have you run into std::localtime() returning UTC? I have posted about it separately. And I am curious about the Rust GUI PoC. For me TouchGFX is not only an authoring barrier, it is the specific reason I cannot build natively at all. A non TouchGFX GUI path would turn my emulated loop into a native one, so I would be interested in how far you got.