Problem: The previous code was printing debug output so that I could
ensure that my argument checking worked correctly, but we don't want to
distribute a binary that echoes back your arguments to you.
Solution: Remove the debug output and add lots of comments to document
all of my misunderstandings of how the current code works. :~)
Problem: I don't know what I'm doing and can't figure out how to
cross-compile this simple C program to macOS and Windows
Solution: @cryptix reminded me that Go makes cross-compiling easy, so I
took a stab at writing my first Go program. It seems to be working on
macOS and Linux, but I haven't tested on Windows.
Problem: Apparently one of the previous commits switched us to
shell-style argument expansion.
Solution: Use the appropriate solution on Windows, `%*`.
Problem: We were using `darwin` instead of `win`.
Solution: Replace `darwin` with `win` to ensure that we're using the
correct path in the batch file we produce.
Problem: When running the Darwin binary from another directory, the
script would look in the user's current working directory for both
`node` and `src`, which is wrong.
Solution: Set `BASEDIR` and use it so that we use the correct paths.
Problem: I've quickly learned that cross-compiling is a major headache
and that C programming lacks both rainbows and butterflies. It seems
that my executable only works on Linux, but probably not macOS or
Windows.
Solution: Use shell scripts on macOS, which work when you double-click
them, and batch scripts on Windows, which I *think* work when you
double-click them. I haven't tested this on a macOS device yet, but I
tested the previous shell script on macOS and it seemed to work fine.
Unless I've done something silly, this should work on macOS, but the
Windows batch script is just me writing code from memory and probably
doesn't work correcly. I'll probably beg @SoapDog to help me fix it.
Problem: Writing C in a heredoc is super janky and I think it's worth
avoiding whenever we can. We've also been getting compiler warnings that
we should probably resolve.
Solution: Move the C to its own file and resolve the compiler warnings.
Problem: The shell script didn't work on other platforms and the
AppImage hack ended up confusing people who tried to install it with
AppImageLauncher.
Solution: This feels absolutely ridiculous, but I've written the worst C
program in the world which does the equivalent of `exec ./node src "$@"`
and immediately gets out of our way. This ends up being an executable
that both Nautilus and Dolphin (GNOME and KDE file managers) let us
double-click, and should also work on macOS. It might even work on
Windows if we rename it as an `.exe`, but I'm not sure and *definitely*
haven't tested that.
Problem: We try to `require()` our native modules to ensure that they
work correctly, but when they don't work we need to produce an error
that will help us debug the problem.
Solution: Switch from `node -p` to `node -e` to avoid printing
unnecessary output and don't redirect output for mandatory modules so
that we can debug them.
Problem: The installer contained npm and npx and a bunch of code that we
really don't need unless we're building from source. Since we don't want
our end-users to build anything from source, we can remove these.
Solution: Use shell-check to make some small fixups to the code and
remove everything we're downloading via wget except the `node` binary.
This requires moving the "build from source" fallback, and also includes
the `.appimage` hack when building from Linux to get double-click
opening working.
Problem: The previous approach of having the installer run `npm install`
was hazardous at best and didn't work well offline.
Solution: Package all of the source code with the application and use
the installer to ensure that it works on the target device. The
installer should ensure that we can `require()` the module, and if that
doesn't work then it should choose between two options:
- If the module is optional, `rm -rf` it and don't worry about it.
- If the module is mandatory, try running `npm install` with some flags
to ensure that we stay offline and print the absolute minimal output.
This should never happen, because we should never be packaging Oasis
for architectures and platforms that we don't have prebuilds for, but
it's a fine fallback behavior for experimental hackery.
Problem: Running `./oasis --version` should output the current version,
it shouldn't just start the server by default.
Solution: Pass through command-line arguments with `$@` so that we
respect what the user is asking us to do.
Problem: Most people don't have npm installed and we probably shouldn't
force them to have a full development environment to use Oasis. It would
be nice to have a way to install Oasis without any development tools.
Solution: Add a build script that can create .zip files that work on
Unix systems like macOs and Linux. Users will need to download the zip,
extract it, and double-click the `oasis` script. This script will run
`npm start || npm install && npm start`, which uses binaries that we
ship in the zip file so that they don't need to have `node` or `npm`
installed.
Christian Bundy