torc 0.22.2

# Cross-Compilation Test Results

## Test Summary

**Date**: 2025-11-24 **Status**: ✅ **LIKELY TO SUCCEED** with recommended changes

## Binaries Tested

✅ `torc` (client + TUI + plot_resources) - Builds successfully ✅ `torc-server` - Builds
successfully ✅ `torc-slurm-job-runner` - Builds successfully

## Dependency Analysis

### 1. Kaleido (plotly) - ✅ GOOD

**Status**: Should work across all platforms

**Analysis**:

- `plotly_kaleido` downloads pre-built binaries at build time
- Supports all our target platforms:
  - ✅ Linux x86_64
  - ✅ Linux ARM64 (if needed later)
  - ✅ macOS ARM64 (Apple Silicon)
  - ✅ macOS x86_64 (Intel, if needed later)
  - ✅ Windows x86_64

**Source**: https://github.com/plotly/Kaleido/releases/tag/v0.2.1

### 2. OpenSSL - ⚠️ NEEDS ATTENTION

**Status**: Will likely fail on musl builds without changes

**Current situation**:

- `torc-server` depends directly on `openssl` crate
- Main `Cargo.toml` has `openssl-sys` with `vendored` feature for dev-dependencies only
- Musl builds require vendored OpenSSL or static linking

**Issue**: Cross-compilation with `cross` tool might fail for musl targets if OpenSSL isn't vendored
for release builds.

### 3. Other Dependencies - ✅ GOOD

**SQLite** (via rusqlite):

- Uses `bundled` feature - will compile from source
- Works perfectly for all targets

**TUI dependencies** (ratatui, crossterm):

- Pure Rust, no native dependencies
- Should work fine everywhere

## Recommended Changes

### Option 1: Use vendored OpenSSL for musl builds (RECOMMENDED)

Add to `torc-server/Cargo.toml`:

```toml
[dependencies]
# ... existing dependencies ...

[target.'cfg(target_env = "musl")'.dependencies]
openssl = { workspace = true, features = ["vendored"] }
```

This ensures OpenSSL is statically compiled into the binary for musl targets.

### Option 2: Enable vendored OpenSSL globally for release builds

Set environment variable in the GitHub workflow:

```yaml
- name: Build binaries (with cross)
  if: matrix.use_cross
  env:
    OPENSSL_STATIC: "1"
    OPENSSL_LIB_DIR: "/usr/lib"
    OPENSSL_INCLUDE_DIR: "/usr/include"
  run: |
    cross build --release --target ${{ matrix.target }} ...
```

### Option 3: Let `cross` handle it (EASIEST - TEST FIRST)

The `cross` tool includes OpenSSL in its Docker images. The workflow may work as-is.

**Recommendation**: Try the workflow as-is first. If it fails with OpenSSL linking errors, implement
Option 1.

## Potential Issues to Watch

### 1. Kaleido Download Failures

**Symptom**: Build fails with "failed to download kaleido" **Cause**: GitHub rate limiting or
network issues **Solution**: Builds run on GitHub Actions should have good connectivity

### 2. Windows OpenSSL

**Status**: Already handled correctly **Evidence**: Existing test workflow successfully builds on
Windows using vcpkg

### 3. Binary Size

**Observation**: Musl builds with vendored OpenSSL will be larger **Mitigation**: Already using
`--release` flag. Consider adding strip step:

```yaml
- name: Strip binaries (Unix)
  if: matrix.os != 'windows-latest'
  run: |
    strip target/${{ matrix.target }}/release/torc
    strip target/${{ matrix.target }}/release/torc-server
    strip target/${{ matrix.target }}/release/torc-slurm-job-runner
```

## Test Plan

### Phase 1: Test workflow as-is

1. Push a test tag: `git tag v0.7.0-test && git push origin v0.7.0-test`
2. Monitor GitHub Actions
3. Check if all builds succeed

### Phase 2: If musl build fails with OpenSSL errors

1. Implement Option 1 (vendored OpenSSL for musl)
2. Push another test tag: `git tag v0.7.0-test2 && git push origin v0.7.0-test2`
3. Verify success

### Phase 3: Validate binaries

Download and test each binary:

```bash
# macOS
./torc --version
./torc-server --version

# Linux (test on Alpine, Ubuntu 20.04, Ubuntu 24.04)
./torc --version
./torc-server --version

# Windows (PowerShell)
.\torc.exe --version
.\torc-server.exe --version
```

## Conclusion

The workflow is well-designed and should work with high probability. The main risk is OpenSSL
linking on musl, but this has known solutions. All other dependencies are either pure Rust or
download pre-built binaries.

**Confidence Level**: 85% success without changes, 99% with OpenSSL vendoring

**Recommended Action**: Test the workflow as-is. Have Option 1 ready if needed.