rust-cross VS just

rust-cross, Everything you need to know about cross compiling Rust programs! - Jorge Aparicio

on: push: tags: - 'v*' name: Cross-compile and release jobs: build: name: Build runs-on: ubuntu-latest strategy: matrix: target: # https://github.com/japaric/rust-cross#the-target-triple - x86_64-unknown-linux-gnu - x86_64-pc-windows-gnu - wasm32-unknown-emscripten steps: - uses: actions/checkout@v2 - uses: actions-rs/toolchain@v1 with: toolchain: stable target: ${{ matrix.target }} override: true - uses: actions-rs/cargo@v1 with: use-cross: true command: build args: --release --target=${{ matrix.target }} release: name: Release needs: [ build ] runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 with: clean: false - uses: nowsprinting/check-version-format-action@v3 id: version with: prefix: 'v' - name: Create release id: new_release uses: actions/create-release@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ github.ref }} release_name: Release ${{ github.ref }} body: | Changes in this release: - First change - Second change draft: false prerelease: false - name: Upload 64-bit Windows build uses: actions/upload-release-asset@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: asset_path: target/release/client.exe asset_name: client-${{ matrix.target }}-${{ steps.version.outputs.full }}.exe asset_content_type: application/zip upload_url: ${{ steps.new_release.outputs.upload_url }} - name: Upload 64-bit Linux build uses: actions/upload-release-asset@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: asset_path: target/release/client asset_name: client-${{ matrix.target }}-${{ steps.version.outputs.full }} asset_content_type: application/zip upload_url: ${{ steps.new_release.outputs.upload_url }} - name: Upload 32-bit WebAssembly build uses: actions/upload-release-asset@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: asset_path: target/release/client.wasm asset_name: client-${{ matrix.target }}-${{ steps.version.outputs.full }}.wasm asset_content_type: application/zip upload_url: ${{ steps.new_release.outputs.upload_url }}

Well, at least that's that easy if what you try to compile don't have C dependencies. For C dependencies, there is cross <https://github.com/japaric/rust-cross> which I had good experiences with.

Oh, this was the first thing that came up: https://github.com/japaric/rust-cross

> If I had to submit one tip it would be to set everything up with a Makefile or similar.

If I had to submit a tip on top of yours, it's to use justfiles instead of Makefiles :-)

https://github.com/casey/just

If you’re going to use make, use just instead:

https://github.com/casey/just

I was curious to see this simulation running but there does not seem to be a running demo.

I don't know if this is your creation or not, but I would really recommend having a running demo before publicizing work. It is a sad reality in software that, no matter how much time and artistry is placed into a work, it needs to be rapidly consumable for it to be properly shared.

Speaking for myself, I have a backlog of at least 50 projects, with at least 5 I jump around actively, while learning foreign languages, hiking, and living life. As much as I want to see a slime mold simulation, if it doesn't run when I check the repo with a demo link that functions on my phone, my curiosity will have to end there.

5 minute later: alright so my curiosity didn't end. It looks like the project is using 'just' for command running (for those unfamiliar, https://github.com/casey/just). It isn't my preferred way to do things but you probably have it already like I do.

20 minutes later: alright so after cloning the repo and running "just demo 512x512" (it needs a resolution), it doesn't run. It uses assert statements so the application crashes when it fails assertions. We are in trouble because it doesn't gracefully select a texture format. I printed what my gpu supports and tried to find a best match.

After that, it doesn't support the requested blend mode, so I switched it to one that my gpu supports.

When making a gpu app, make sure to adapt based upon the capabilities a GPU supports. It isn't much harder to do this, while making it significantly more accessible for anyone using it -- even for fun or experimenting.

While it runs, it doesn't do anything -- likely because it isn't running with the expected texture format and blend modes.

Unfortunately, while I really want to see a slime mold simulation, I have to stop now before I refactor this entire project and make it consumable for anyone curious. Then I will have a working "slime mold simulation" at the end of the day, and I am not sure how helpful that would be to anyone, including myself.

My first thought was that that was dropping one of the main features of make.

On reflection though, the timestamp dependant part isn't really something used much nowadays apart from compiling C.

It'd be cool if it was an opt-in feature for just files so that it could actually function as a replacement for make in all cases.

I went looking in the docs and found this[0] which I'd missed last time I looked into justfiles.

[0] https://github.com/casey/just?tab=readme-ov-file#what-are-th...

Most projects I've worked on included a bunch of scripts for common tasks (installing dependencies, starting/stopping dev servers, testing and deploying changes, and so on). There are a few tools designed for this, such as Just (https://just.systems/) and Task (https://taskfile.dev/), and I know some people use Make as a task runner (e.g. https://news.ycombinator.com/item?id=40333481), but I've always preferred the simplicity and universality of shell scripts.

Bin CLI is a tool I wrote to add some of the niceties of these tools to shell scripts: it works even when you're currently in a subdirectory, only requires you to type enough of the command (script) name to uniquely identify it, and allows aliases to be defined. It also allows a project's commands to be listed (along with some help text), supports subcommands, and supports tab completion of command names. Of course scripts can be written in other languages too, just by adding the appropriate shebang.

Collaborators/contributors who don't have Bin CLI installed can just run the scripts directly - so I can enjoy the benefits without adding a hard dependency or extra barrier to entry. However, I also added support for defining one-liner scripts/aliases in a config file (much like "npm run" scripts are defined in package.json) for times when I want to avoid creating many trivial/wrapper scripts for common tasks.

It is implemented as a single Bash script, with minimal dependencies, small enough to keep in my Dotfiles repo (62 KB). I also made .deb and .rpm packages so it can easily be installed system-wide.

I find `just` to be better suited than `make` for this use case: https://github.com/casey/just

The siblings comment is good too, and often I'll put all the various commands into a subdir, and `just` is just an interface to that, particularly so if the script gets complex.

Then, `just` is really a signal "hey, this repo supports this interface" and things like `just -l` for discoverability.

I don't like makefiles, but I've been enjoying justfiles: https://github.com/casey/just

I started using just [0] on my projects and have been very happy so far. It is very similar to make but focused on commands rather than build outputs.

Define your recipes and then you can compose them as needed.

[0] https://github.com/casey/just