Kakoune.cr

Terminal Tools
21

Just added the support for static builds.

You don’t need Crystal but Docker for building.

Installation

Run make install static=yes or make release for static builds.

The latter generates a target/release.zip that you can ship everywhere.

4 Likes
22

People are complaining about it’s being written in Crystal, but I don’t see it as a problem (specially if you can provide binaries in its releases).

I added it too. =D

2 Likes
23

@alexherbo2 you should add static builds for the major platforms to the github project (a lot of Go & Rust projects do this) … not sure if there is an upcharge or if it is free on github, but I am sure some of us would donate a bit to get those binaries up.

1 Like
24

I don’t know how to do. I have read @TeddyDD’s gist but I don’t understand all the lines.

25

It is a github action responding to push or pull_request (merge) to master. It fires up a docker – builds kcr and then adds to to the github releases page (I think).

If Crystal can cross-compile for Mac from a linux docker, doing a similar thing for Mac would be straightforward. I wonder if Crystal could output both arm and intel builds for the Mac?

26

I was able to cross-compile on Mac for Linux arm64 using this guide. Command I used:

crystal build --cross-compile --target "aarch64-unknown-linux-gnu" --release -o kcr src/cli.cr

llvm target for Mac x86_64 would be:

❯ /usr/local/opt/llvm/bin/llvm-config --host-target
x86_64-apple-darwin20.3.0

so to cross-compile on Linux for Mac there is need to replace target with x86_64-apple-darwin20.3.0 or I suppose just x86_64-apple-darwin will suffice.

2 Likes
27

Cross-compiling can be difficult, because it’s not just about emitting a binary for the target platform, it also involves linking with libraries for the target platform.

I haven’t tried it with Crystal, but in my experience:

  • anything can cross-compile for Linux, because Linux has a stable syscall interface which means the compiler can just hard-code things
  • it’s possible to cross-compile for Windows as long as you’re using the MinGW toolchain, since it includes definitions of Windows APIs and freely-distributable libraries to link against
  • only Windows can build Windows binaries using the Visual C++ toolchain, since Microsoft only permits them to be installed on Windows
  • only macOS can build macOS binaries, since Apple only allows the compiler and toolchain to be installed on Apple hardware

GitHub Actions does provide macOS build agents, so you can build macOS binaries automatically. However, GitHub does not (yet) have macOS build agents running the latest OS version with the latest build tools, so building ARM binaries is not possible.

28

Just added a release with static builds for Linux.

4 Likes
29

@alexherbo2 amazing! Next up Mac? :slightly_smiling_face:

This actually reduces my stress about using this as a drop in replacement for connect.kak a great deal (I might swap to it once Mac builds are up).

1 Like
30

Next is macOS, but I haven’t a strong experience with GitHub Actions yet.

31

Great! While you’re still on this, usually archives are named against the target you’ve built the executable for. So in this case I guess it would be someting like kakoune_cr-x86_64-unknown-linux-musl.tar.gz. This way it helps to distinguish platforms, when there are several builds

32

Honestly – static builds in Crystal, Rust, Go with Github actions really open up the field for lots of interesting stuff like this… and honestly the first language with a great “Kakoune Support” library that makes it super easy to interact with kak, that can also do static builds could become a defacto winner.

33

Anyone familiar enough with homebrew (macOS package manager) to add kakoune.cr there?

34

@basbebe as someone who newly converted from linux to mac for my daily driver (M1 chip reasons). I have been wanting this (specifically the build from source with native M1 support) so I might jump on it. Kakoune stable builds are already in it.

That said, I have zero experience with it.

35

macOS is now supported! :partying_face:

2 Likes
36

I took your recommendation to name according to the target triple thanks!

They are now named kakoune.cr-nightly-x86_64-unknown-linux-musl.zip and kakoune.cr-nightly-x86_64-apple-darwin.zip.

37

@alexherbo2 very cool, and acts as a guide for anyone else building Kakoune plugins in Crystal – are you paying any additional for these builds?

38

@robertmeta No, GitHub offers it for free.

If you want to get started with the GitHub Actions, I suggest you to follow the “Get started with Actions” from their homepage and read the “Quickstart”.

After reading it, take one of your projects and start to experiment by creating a private fork, so you will not pollute your main repo.

There are plenty of contributed GitHub Actions on the Marketplace, but I wanted to stick with the minimum and use the CLI tools I knew as if I were to build locally.

In the Quickstart, you can quickly get what is done and start tweaking your own .github/workflows/release.yml.

Each job has a name, a machine to run on and steps to fulfill its purpose.

For creating the releases, I needed:

The actions (jobs) run in parallel, so you need needs: release to ensure the first job named release has finished before starting the Linux and macOS machines.

2 Likes
39

Should we deprecate connect.kak and prelude.kak? Or maybe include links from their READMEs to kakoune.cr as their successors? I was very confused when Autopairs stopped working for me and I had to go to its README to learn that it depends on kakoune.cr now. I think doing some of these things would prevent others from also being confused

40

connect.kak and the prelude were marked as archived, but @robertmeta revived them.

Sadly the README got updated and the links were removed by inadvertance.