One of the things that I compiled on my Librem 5 was the Magic Set Editor 2, from here:
It looks about like this when not docked:
I also compiled the NetSurf browser to run on my Librem 5, although sometimes I have been forgetting to use it and was instead using Epiphany or Firefox because of the addicting power of senselessly running nonfree javascript to communicate with the nonfree world.
So, regardless of that, I figured I would bring this up because my experience seems to have been quite different from yours. When I wanted to build this application on the Librem 5, basically I downloaded the CMake project, then followed the instructions for building it. And this application is a very old C++ application with 17 years of commits in the repo, and because of its age and because I had never used wxwidgets before, I was stuck for a little while on compiling until I went and actually read through their C++ code and realized that they were using a raw C programming varargs concept in some way that modern g++ was rejecting. But I changed this to a variadic template and all the problems went away and the program compiled and just started working. I would assume that I would have had the same issue on any standard modern GNU/Linux computer that had a newer version of WxWidgets that no longer supported their old WxString varargs printf or whatever it was.
So, it’s not as if we don’t have to get our hands dirty to accomplish our goals sometimes, but I don’t think I encountered the kind of issues that you are describing… really at all. Essentially, I downloaded the C++ / CMake project with a basic git clone <whatever> from inside a folder like /home/purism/repos/<nameofproject> that I had created, and then I ran the basic cmake commands to compile that project. Are you trying to compile something immensely complex that requires an extraordinary amount of RAM just to compile? In my head, the Magic Set Editor 2 is a fairly complex program because of how it supports 20 years of different cards styles and settings and special font formatting for card cost symbols, and special autocomplete for the syntactical descriptions of powers and abilities. But I guess at the end of the day, it is a harmony of graphics and text like a word processor in a way. And, I did compile it while my device was docked so that I could treat it like a Linux PC rather than a handset.
But I don’t really recall it taking all that long to compile this. Maybe it took some time, but it felt reasonable to me at the time. Is your problem that building applications on the Librem 5 is taking too long? Or is it physically not working at all due to some error?
When I use cmake, per the instructions on the Magic Set Editor 2 example (which matches almost every other cmake project I ever used), I basically just cmake build -DCMAKE_BUILD_TYPE=Release or something similar to it, and by invoking cmake on command line then the project setup is created, and then afterwards we can invoke the project build such as by using make or ninja or whatever cmake was configured for. But in the case of the Magic Set Editor 2 they save us time by suggesting to have cmake pick for us by just using cmake --build as the second command to type that actually compiles the application.
So, that has all worked quite well for me.
Option 2: This might be physically possible but for these few projects that I compiled myself, I never felt the slightest need to make a swap file like that because 3 GB of memory seemed like it was usually enough to compile most things.
Option 3: I tried using qemu for the Librem 5 img a week or two ago for something I was doing and I kept doing it wrong. There must be a tutorial somewhere, and I didn’t look in the right place. So maybe someone else can help. But I managed to get a crappy ubuntu QEMU setup that was specifically running ubuntu aarch64, and it was miserable. The aarch64 emulation on a big PC with 64 GB of RAM and a Ryzen 7 2700x processor and an nVidia 2080 Ti 11GB card was abysmally slow, even when I told the aarch64 qemu configuration to use 8 cores and tons of RAM. Just getting to the point of booting took hours.
Option 4: Seems very project specific. Maybe you could try it and tell us what kind of problems you encounter? I tried dual-booting my Librem 5 into a second install of PureOS that was using landing instead of byzantium repos, and when I tried to compile the latest axolotl binaries in rust and then copy them back to the byzantium version of the Librem 5, it was a terrible idea and exploded everything. A lot of the shared libraries simply did not match across versions, so running a binary with at on of dependencies simply did not work. As you kind of suggested, after apt-get installing the necessary binaries in the landing version of PureOS mobile, I tried to physically manually copy them from /lib/aarch64-linux-gnu/<thing>.so from one to the other and what I ended up doing was corrupting the basic functionalities of my PureOS installation so that even web browsing did not work, and then I reinstalled PureOS byzantium elsewhere and copied again back to having the byzantium versions and got it working again but it was all very crazy. I think it’s cool that free software allows us to make mistakes like that, but also I think that doing that is a mistake.
