remake

remake is a small command line helper that lets you build and test your project on a remote machine, while you keep editing locally on your own workstation.

The typical scenario is a developer working on a macOS arm64 laptop, with the real target environment being a Linux x86_64 server. Instead of manually uploading files, SSHing in, and re-running make, you can run a single command:

remake

It synchronises your working directory to the remote host with rsync, then runs the build and tests directly on that machine. You see the output in your local terminal as if everything was happening on your laptop.

This version adds two important features:

• By default remake performs both build and test (sync → build → test).
• The configuration can define multiple remote targets, selected with -t.

Features

• Project-local configuration with a .remake.conf file
• Syncs the current project directory to a remote path using rsync
• Streams output from remote build and test commands back to your terminal
• Simple subcommands:
  • remake → sync + build + test
  • remake build → sync + build only
  • remake test → sync + build + test
  • remake run <command...> → sync + run an arbitrary command
• Multiple remotes, selected by name with -t target
• Minimal dependencies: rsync, ssh, and a C compiler

The goal is to keep this tool small, predictable, and easy to understand.

Installation

You need a POSIX-like system with ssh and rsync installed. On most Linux and BSD systems they are already available. On macOS they come preinstalled.

Build remake:

cc -Wall -Wextra -O2 -o remake remake.c

Or use the Makefile:

make

Then move the remake binary somewhere on your $PATH:

sudo mv remake /usr/local/bin/

Configuration

remake looks for a file named .remake.conf starting from the current directory and walking upward until it reaches /. This lets you run remake from any subdirectory inside the project.

A simple configuration covering a single remote might look like this:

[remote]
host = staging.example.com
user = deploy
path = /srv/myproject

[sync]
exclude = .git,node_modules,build

[commands]
build = make -j4
test  = ./run-tests

Multiple remotes

You can define more than one remote by adding extra sections of the form [remote:name]. The plain [remote] section is treated as the default target.

For example:

[remote]
host = staging.example.com
user = deploy
path = /srv/myproject

[remote:prod]
host = prod.example.com
user = deploy
path = /srv/myproject

[sync]
exclude = .git,node_modules,build

[commands]
build = make -j4
test  = ./run-tests

In this setup:

• remake or remake test uses the default remote, defined by [remote].
• remake -t prod test uses the [remote:prod] configuration.

Remote entries are identified by their names:

• [remote] is equivalent to [remote:default].
• [remote:staging] defines a target called staging.
• [remote:prod] defines a target called prod.

Sections

[remote] and [remote:name]

Each remote entry requires:

• host
  Hostname or IP address of the remote machine.

• path
  Directory on the remote machine where the project will be synced and commands will be executed.

Optional:

• user
  SSH user. If omitted, the local username is used.

[sync]

• exclude
  Optional comma-separated list of patterns to pass to rsync --exclude.
  Example: .git,node_modules,build,*.o.

[commands]

• build
  Required when you use remake, remake build, or remake test. This is the command that will be run to build your project on the remote server.

• test
  Required when you use remake or remake test. This is the command that will be run after a successful build, typically your test suite.

Usage

Basic usage with a single remote:

remake

This is equivalent to:

remake test

The sequence is:

1. Synchronise the current directory to the configured remote path using rsync -az --delete.
2. Run the build command from the [commands] section on the remote server.
3. If the build succeeds, run the test command.

To only build without running tests:

remake build

To build and test explicitly:

remake test

To sync and run a custom command without using the predefined build and test entries:

remake run ./myserver --config server.conf

Using targets

When you define multiple remotes, select which one to use with -t:

remake -t staging
remake -t prod test
remake -t prod run ./myserver --config prod.conf

In each case, remake will:

1. Look up the [remote:staging] or [remote:prod] section.
2. Sync the current directory to its path.
3. Run the requested commands there.

Exit codes

• 0 if sync and all requested commands succeed.
• Non-zero if rsync fails, if the configuration is missing required values, or if any remote command exits with a non-zero code.
• 1 for simple usage or configuration errors.

This makes remake usable from scripts or as part of a larger automation workflow.

Example workflow

Imagine you have a C project you edit on macOS, and a Linux server named ssh-server.net where you want to build and run it.

Project structure:

myproject/
  .remake.conf
  Makefile
  src/
  tests/

.remake.conf:

[remote]
host = ssh-server.net
user = remote_user
path = /path/myproject

[remote:prod]
host = prod-server.net
user = remote_user
path = /path/myproject

[sync]
exclude = .git,build,*.o

[commands]
build = make -j4
test  = ./run-tests

From your laptop:

cd myproject
remake

You might see something like:

[remake] syncing to crypto@ssh-server.net:/path/myproject
[remake] sync complete
[remake] === BUILD (make -j4) ===
cc -O2 -Wall -c src/main.c -o build/main.o
cc -O2 -Wall -c src/util.c -o build/util.o
cc -o build/myserver build/main.o build/util.o
[remake] BUILD done
[remake] === TEST (./run-tests) ===
[ RUN ] test_parse_config
[  OK ] test_parse_config
[ RUN ] test_connection
[  OK ] test_connection
[remake] TEST done

Later, when you are ready to exercise the production machine more directly:

remake -t prod test

The same project tree is synced and exercised against the production remote configuration.

Notes

• remake assumes that ssh and rsync are installed and in your PATH.
• Authentication is up to your normal SSH setup. It works best with SSH keys rather than passwords.
• The configuration format is intentionally kept small and direct.