Nice work

Looking good 👍

@ym I'm unable to build your pr as i keep running into this issue (running in vscode dev containers)

[ 54%] Building C object CMakeFiles/jknative.dir/screen.c.o
cc1: warning: /workspaces/kvm/internal/native/cgo/ui: not a directory
/workspaces/kvm/internal/native/cgo/screen.c:10:10: fatal error: ui/ui.h: No such file or directory
 #include "ui/ui.h"
          ^~~~~~~~~
compilation terminated.
gmake[2]: *** [CMakeFiles/jknative.dir/build.make:5063: CMakeFiles/jknative.dir/screen.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/jknative.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Using eez studio to build the ui it, it seems like the ui file its looking for is just an simple text file with in it the link to the actual build files, tho this file is not an systemlink

@ym I'm unable to build your pr as i keep running into this issue (running in vscode dev containers)

[ 54%] Building C object CMakeFiles/jknative.dir/screen.c.o
cc1: warning: /workspaces/kvm/internal/native/cgo/ui: not a directory
/workspaces/kvm/internal/native/cgo/screen.c:10:10: fatal error: ui/ui.h: No such file or directory
 #include "ui/ui.h"
          ^~~~~~~~~
compilation terminated.
gmake[2]: *** [CMakeFiles/jknative.dir/build.make:5063: CMakeFiles/jknative.dir/screen.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/jknative.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Using eez studio to build the ui it, it seems like the ui file its looking for is just an simple text file with in it the link to the actual build files, tho this file is not an systemlink

Could you please provide the full command that you use to build?

For EEZ Studio, its export path should be internal/native/eez/src/ui, internal/native/cgo/ui is a symlink to that directory.

vscode ➜ /workspaces/ymjk (feat/native-as-lib) $ ls -la internal/native/cgo/ui
lrwxrwxrwx 1 vscode vscode 13 Sep 26 10:40 internal/native/cgo/ui -> ../eez/src/ui

vscode ➜ /workspaces/ymjk (feat/native-as-lib) $ ls -la internal/native/cgo/ui
lrwxrwxrwx 1 vscode vscode 13 Sep 26 10:40 internal/native/cgo/ui -> ../eez/src/ui

for me running the same command returns:

-rw-r--r-- 1 vscode vscode 13 Sep 26 10:13 internal/native/cgo/ui

in eez studio i checked the build path and it seems correct

EDIT:
im going to do an clean rebuild of the dev container and see what happens

@ym Could you please explain how we are meant to build and deploy the code now, as using devcontainers is broken

@ym I'm unable to build your pr as i keep running into this issue (running in vscode dev containers)

[ 54%] Building C object CMakeFiles/jknative.dir/screen.c.o
cc1: warning: /workspaces/kvm/internal/native/cgo/ui: not a directory
/workspaces/kvm/internal/native/cgo/screen.c:10:10: fatal error: ui/ui.h: No such file or directory
 #include "ui/ui.h"
          ^~~~~~~~~
compilation terminated.
gmake[2]: *** [CMakeFiles/jknative.dir/build.make:5063: CMakeFiles/jknative.dir/screen.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/jknative.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Using eez studio to build the ui it, it seems like the ui file its looking for is just an simple text file with in it the link to the actual build files, tho this file is not an systemlink

Hi @SilkePilon, @ym,

The issue stems from the scripts/build_utils.sh script, which requires you to run it within docker. Here is an updated version that works with JETKVM_INSIDE_DOCKER=1 (e.g. JETKVM_INSIDE_DOCKER=1 ./dev_deploy.sh -r 192.168.100.214).

I have only ran it within the devcontainer, but it should work outside too, when not setting JETKVM_INSIDE_DOCKER

#!/bin/bash

# check if TERM is set
# though it's not the actual way to detect if TTY is available, it's a good enough approximation for our use case
HAS_TTY=true
if [ -z "$TERM" ] || [ "$TERM" = "dumb" ]; then
    HAS_TTY=false
fi

# default colors
C_RST=$(echo -e "\e[0m")
C_ERR=$(echo -e "\e[31m")
C_OK=$(echo -e "\e[32m")
C_WARN=$(echo -e "\e[33m")
C_INFO=$(echo -e "\e[35m")

# if TTY is available, use colors
if [ "$HAS_TTY" = true ]; then
    C_RST="$(tput sgr0)"
    C_ERR="$(tput setaf 1)"
    C_OK="$(tput setaf 2)"
    C_WARN="$(tput setaf 3)"
    C_INFO="$(tput setaf 5)"
fi

msg() { printf '%s%s%s\n' $2 "$1" $C_RST; }

msg_info() { msg "$1" $C_INFO; }
msg_ok() { msg "$1" $C_OK; }
msg_err() { msg "$1" $C_ERR; }
msg_warn() { msg "$1" $C_WARN; }

DOCKER_BUILD_TAG=${DOCKER_BUILD_TAG:-ghcr.io/jetkvm/buildkit:latest}
DOCKER_BUILD_DEBUG=${DOCKER_BUILD_DEBUG:-false}
DOCKER_BUILD_CONTEXT_DIR=${DOCKER_BUILD_CONTEXT_DIR:-$(mktemp -d)}
DOCKER_GO_CACHE_DIR=${DOCKER_GO_CACHE_DIR:-$(pwd)/.cache}

BUILD_IN_DOCKER=${BUILD_IN_DOCKER:-false}


function prepare_docker_build_context() {
    msg_info "▶ Preparing docker build context ..."
    cp .devcontainer/install-deps.sh \
        go.mod \
        go.sum \
        Dockerfile.build \
        "${DOCKER_BUILD_CONTEXT_DIR}"
    cat > "${DOCKER_BUILD_CONTEXT_DIR}/entrypoint.sh" << 'EOF'
#!/bin/bash
git config --global --add safe.directory /build
exec $@
EOF
    chmod +x "${DOCKER_BUILD_CONTEXT_DIR}/entrypoint.sh"
}

function build_docker_image() {
    if [ "$JETKVM_INSIDE_DOCKER" = 1 ]; then
        msg_info "▶ Already running inside Docker container, skipping image build"
        return
    fi

    BUILD_ARGS="--build-arg BUILDPLATFORM=linux/amd64"
    if [ "$DOCKER_BUILD_DEBUG" = true ]; then
        BUILD_ARGS="$BUILD_ARGS --progress=plain --no-cache"
    fi

    msg_info "Checking if Docker is available ..."
    if ! command -v docker &> /dev/null; then
        msg_err "Error: Docker is not installed"
        exit 1
    fi

    DOCKER_BIN=$(which docker)
    if echo "$DOCKER_BIN" | grep -q "snap"; then
        msg_warn "Docker was installed using snap, this may cause issues with the build."
        msg_warn "Please consider installing Docker Engine from: https://docs.docker.com/engine/install/ubuntu/"
    fi

    prepare_docker_build_context
    pushd "${DOCKER_BUILD_CONTEXT_DIR}" > /dev/null
    msg_info "▶ Building docker image ..."
    docker build $BUILD_ARGS -t ${DOCKER_BUILD_TAG} -f Dockerfile.build .
    popd > /dev/null
}

function do_make() {
    if [ "$JETKVM_INSIDE_DOCKER" = 1 ]; then
        msg_info "▶ Running make inside Docker container ..."
        git config --global --add safe.directory /build
        set -x
        make "$@"
        set +x
    else
        DOCKER_BUILD_ARGS="--rm"
        if [ "$HAS_TTY" = true ]; then
            DOCKER_BUILD_ARGS="$DOCKER_BUILD_ARGS --interactive --tty"
        fi
        if [ "$BUILD_IN_DOCKER" = true ]; then
            msg_info "▶ Building the project in Docker ..."
            set -x
            docker run \
                --env JETKVM_INSIDE_DOCKER=1 \
                -v "$(pwd):/build" \
                -v "${DOCKER_GO_CACHE_DIR}:/root/.cache/go-build" \
                ${DOCKER_BUILD_TAG} make "$@"
            set +x
        else
            msg_info "▶ Building the project in host ..."
            set -x
            make "$@"
            set +x
        fi
    fi
}

@ym maybe it's worthwhile to use this after testing it a little on another machine that is different from mine? I don't have an X86 machine nearby to test on unfortunately right now, so I ran it using the following:

cd /path/to/repo-root
# Build the workspace
export DOCKER_DEFAULT_PLATFORM=linux/amd64 && devpod up . --id jetkvm-tmp
# SSH into the devpod workspace
devpod ssh jetkvm-tmp
# Wait for it to build

# Or just deploy...
JETKVM_INSIDE_DOCKER=1 ./scripts/dev_deploy.sh -r 192.168.100.214

P.S. Awesome stuff @ym !

Hope it helps!

Thanks,
Alex

@pennycoders @SilkePilon

If you’re using the devcontainer from this branch, or already have all dependencies installed, please run the following command (note the --disable-docker flag):

./dev_deploy.sh --disable-docker -r 192.168.100.214

Otherwise, the default should be sufficient:

./dev_deploy.sh -r 192.168.100.214

The initial build may take ~6 minutes on an M1 MacBook, but subsequent builds should finish within ~1 minute.

By default, the Docker build option is enabled. We assume most developers don’t have all dependencies installed, and the performance penalty is barely noticeable. This makes it easier to get started. We’ve tested it on macOS 26 w/ OrbStack and on a Debian 13 VM w/ Docker CE, and it should work flawlessly.

One exception is Ubuntu (snap-based Docker), as @adamshiervani found, it will always complain that Dockerfile.build doesn’t exist when using the snap Docker package.