111 lines
2.7 KiB
Markdown
111 lines
2.7 KiB
Markdown
|
+++
|
||
|
|
title = "Relm on Windows"
|
||
|
|
+++
|
||
|
|
There are essentially 2 methods for compiling Gtk apps
|
||
|
|
|
||
|
|
- using *msvc* compiler and .LIB files
|
||
|
|
- using \"gnu\" backend and msys2 libraries
|
||
|
|
|
||
|
|
It is a pick your poison situation, the first option requires unpacking
|
||
|
|
zip files and organizing stuff so the rust compiler can find the
|
||
|
|
libraries and the runtime the DLLs.
|
||
|
|
|
||
|
|
The other option requires configuring rust to essentially cross compile
|
||
|
|
to the *x86~64~-pc-windows-gnu* target.
|
||
|
|
|
||
|
|
Since I know how to cross compile from my recent experiments with
|
||
|
|
compiling for embedded ARM processors and I generally know my way better
|
||
|
|
around the unixy msys environment, the latter it is.
|
||
|
|
|
||
|
|
# Installing Gtk in Msys2/Mingw64
|
||
|
|
|
||
|
|
Installing gtk3 is easy as it can be installed with *pacman*
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ pacman -S mingw64/mingw-w64-x86_64-gtk3
|
||
|
|
```
|
||
|
|
|
||
|
|
Add some support for integrating with c libraries and linking, etc...
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ pacman -S mingw-w64-x86_64-toolchain base-devel
|
||
|
|
```
|
||
|
|
|
||
|
|
Being optimistic I installed glade. Probably wont need it today but it
|
||
|
|
is a good test to see if Gtk apps at least start.
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ pacman -S mingw-w64-x86_64-glade
|
||
|
|
```
|
||
|
|
|
||
|
|
Glade starts and shows the GUI so the first milestone was reached.
|
||
|
|
|
||
|
|
# Preparing rust and cargo
|
||
|
|
|
||
|
|
First install the cross compilation target
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ rustup target add x86_64-pc-windows-gnu
|
||
|
|
```
|
||
|
|
|
||
|
|
I can now compile with
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ PKG_CONFIG_ALLOW_CROSS=1 cargo build --target=x86_64-pc-windows-gnu
|
||
|
|
```
|
||
|
|
|
||
|
|
To always enably this environment variable in the project folder I added
|
||
|
|
a *.env* file with
|
||
|
|
|
||
|
|
``` example
|
||
|
|
PKG_CONFIG_ALLOW_CROSS=1
|
||
|
|
```
|
||
|
|
|
||
|
|
which is picked up by the zsh dotenv plugin when I enter the folder.
|
||
|
|
|
||
|
|
Similarly we can change the default target for cargo with adding
|
||
|
|
|
||
|
|
``` example
|
||
|
|
build]
|
||
|
|
target = "x86_64-pc-windows-gnu"
|
||
|
|
```
|
||
|
|
|
||
|
|
to \*.cargo/config.toml
|
||
|
|
|
||
|
|
We can now simply do
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ rust build
|
||
|
|
```
|
||
|
|
|
||
|
|
or
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ rust run
|
||
|
|
```
|
||
|
|
|
||
|
|
# Using VSCode
|
||
|
|
|
||
|
|
When using *vscode* the rust language server needs to have this
|
||
|
|
enviroment setup too so it can do its magic. For debugging and running
|
||
|
|
you can do this in *launch.json* by setting the variables in the *env*
|
||
|
|
property, but this is (logically) not used for the language server.
|
||
|
|
There seem no way to have *vscode* respect the *.env* file soon enough
|
||
|
|
for the language server to pick it up.
|
||
|
|
|
||
|
|
The solution I settled on was to launch *vscode* from the command line
|
||
|
|
in the project folder:
|
||
|
|
|
||
|
|
``` example
|
||
|
|
$ code .
|
||
|
|
```
|
||
|
|
|
||
|
|
The prompt returns immediately and *vscode* is seeing the same
|
||
|
|
environment as the shell. (This does imply that the vscode bin directory
|
||
|
|
is on the path.)
|
||
|
|
|
||
|
|
Of course this wisdom was gained by fixing 1 error message after another
|
||
|
|
while trying to build an example in a 2018 blogpost. In hindsight I
|
||
|
|
could have started with the examples provided with the relm sourcecode,
|
||
|
|
but where would be the fun in that?
|