yeah, I tried forcing this option, because simply supplying --with-own-lws=/usr/lib/x86_64-linux-gnu didn't work, configure was trying to use '/usr/lib/x86_64-linux-gnu/libs/libwebsockets.a', which was annoying.
Ah, that won't work. This arg has the configure script expand the custom path with /libs for ld (to find the binaries) and /include for gcc (to find the headers). It fully expects a cloned repo structure, not a system install (where headers and libs are in completely different folders).
despite my compile working with the Makefile.am edits, there's a real possibility that it will exhibit different behavior and/or bugs to what you're building, right? I'm thinking this because LWS is linking to libev _not_ libuv (although is one not a fork of the other... I am out of my depth here really)
It shouldn't diverge that much.
Is it not the case that going with the distro LWS is a better option anyway?
Until recently, Ubuntu didn't package LWS 3+. I started using LWS when Ubuntu packaged LWS1, and LWS2 just had come out with a new model for the main callback. The 2 versions were not compatible but I wasn't going to wait for Ubuntu to catch up. LWS itself kept pushing major releases in quick succession, with minor backwards compatibility breakage (hence the update to LWS3-4, which don't work with LWS2, but work with one another), and now modern distros carry at least LWS3, so it makes sense to finally allow building vs system installs.
Surely having a custom built in-tree LWS will be harder to maintain
There may be some confusion here. When I started working on Armory, the major open source dependencies were copied as is in the armory source repo (besides python). I guess that's what you're referring to when you say "in tree". I'm trying to get rid that practice. At the moment, gtest, libbtc and chacha20poly1305 still exist as copies in repo. LWS, LMDB and protobuf are out. There is no python dependency anymore. My intent is to evict as much foreign code as possible from the repo before the next release. As a result, at least libbtc and gtest will go too, soon.
Libs were copied in the armory source primarily as a way to ease the building across environments. System libs may vary across distros, Mac has mostly been a blackbox and you can't really install system libs on Windows.
The new approach is to get rid of all the copied code, let the default config look for system libs and allow users to feed it adhoc paths to their own builds of the dependencies. This is how LWS is treated and how all libs will be treated eventually. In this scenario, there's no burden to keep updating the dependencies code, while it's flexible enough to eventually build on any system.
I can later add a helper script that will download the source from the relevant repos, build the dependencies and feed the paths to the cmake project to ease as the "easy to build" DIY solution that should work across all OS. I'll keep on using autohell and manual setups on my own system.
On the other hand, Armory builds much faster now, unless I'm making a hilarious mistake
Cleaned the warnings and got rid of SWIG, that should have speed things up. Also, computers did get faster since =D.