2.2.4 Cycle 4 - Compiling for Windows
Design
Objectives
The main objective in this cycle is to allow the software to be compiled and ran on multiple operating systems, apart from just macOS. The key OS here is windows, but I will also be trying to get compilation working for Linux.
Usability Features
For the compilation, I would like to make it so that the user just selects which OS they are using on the website and download only the correct version, however that would take up too much time at this point of the project and can be added later on, therefore for now the user will just download all available versions of the program and run the one that their system can handle.
Make it clear which version of the program the user should run based on their system using a brief summary.
Not crash the computer if the user runs the wrong version.
Development
This was a lot more tricky than I had first anticipated, since once I started working on this cycle, the configuration was all running fine and had passed all the tests I ran it through on my laptop, so to start compiling for multiple OS all I thought I had to do was add some flags to the compiler inputs but sadly it was not quite that simple.
The V docs suggested it was as simple as I hoped (available here), but it turns out that because the laptop I have been using to create this project runs using an ARM64 chip as opposed to a traditional x86 one, there were some more issues.
What was supposed to happen:
All that I was supposed to have to do was add two new functions to my builder settings, one of which specified the OS to be Linux as follows:
v -os linux ./src/And one for Windows:
v -os windows ./src/Then the code should've been compiled, packaged with the other versions and uploaded to the webportal ready for download.
What actually happened:
Windows
Running the windows compilation appeared to work fine at first, however it did end up having some weirder issues regarding text inputs not being collected properly.
I managed to fix this fairly easily by forcing the results of the inputted data to be a string using `.string()` and that seemed to be the end of that error, although because an arm64 macOS and x86 windows is so fundamentally different I expect to see more errors of this kind later on in the project or during user testing when a variety of systems are tested using the same program.
Linux
Linux however, did not want to work at all.
(The above screenshot is actually from later on in the project which is why some cryptography modules are installed, but the error is very similar to the ones I was seeing during this cycle)
A lot of the errors I received in the approximate week I spent trying to debug and fix these compilation errors were claimed to be dependency and clang issues, however I had ensured I had all the correct dependencies installed so either they weren't being loaded correctly, or the CPU architecture of my laptop seemed to not be playing very nice with the Linux compiler system built into Vlang. Either of those are valid reasons since according to similar issues I could find on the internet, a lot of the people facing this issue have a laptop similar to mine.
I then tried compiling and running the software directly on a Linux machine I had and it worked perfectly, so since Linux users tend to also be a lot more used to git and terminal usage, they should be able to just follow the documentation in the project's readme and compile it themselves, hence after this point I decided just to compile for macOS and windows and let other users compile the project themselves.
This is something I would like to change in the future if I have the time, but realistically it will probably remain like this.
Testing
Tests
1
Compile for Windows.
Node program to compile and execute normally.
Node program compiled and ran but with weird input bugs.
Fail
2
Compile for Linux.
Node program to compile and execute normally.
Node program did not compile.
Fail
3
Recompile for Windows with input changes.
Node program to compile and execute normally.
Node program compiled and ran seemingly normally.
Pass
4
Run the Windows version on a non-windows system.
Computer running incorrect program should report some kind of error and close the program.
Using a MacOS device it is as expected.
Pass
Evidence
Sadly I cannot provide evidence for test 1 as I forgot to collect evidence of the test before fixing the errors resulted from and could not recreate the error without rewriting a large chunk of the configuration handler.
Evidence for test 2 & 3 can be found above in the screenshots within the area "What actually happened".
Test 4
Last updated