* never try to write anything to the host's disks
* read as little as possible from the host's disks
* keep source in ram
* cache build artifacts and intermediate content persistently
Most of these hacks are only necessary because Docker disk performance on macOS is...not performant
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The workaround was put in place as an attempt to get virtual builds going on
macOS, natively. It wasn't enough, and it doesn't work, so lets drop it.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We can pass arguments to the entrypoint from the `docker run` commandline, so we
do not need to do that via an environment variable. This way, we're an
environment variable and an `eval` shorter.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to reproduce things, and to help build in a clean environment,
this adds a thin Dockerfile that has Arduino and arduino-cli pre-installed, and
- along with the `bin/run-docker` script - is set up so that one can easily run
arbitrary commands in the context of the current bundle and Kaleidoscope.
The first run will take a while, because docker will build the image. Subsequent
runs will use the cache.
To use: `bin/run-docker make`, for example. Any argument passed to the
`bin/run-docker` will be eval-ed within the container, and will run there.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In order to be able to access the devices as the at-seat user, without having to
fiddle with distro-specific permissions and groups, we need to tag it both
`uaccess` and `seat`, and have the rule sorted before the one that applies
permissions based on these tags. As such, the file had to be renamed as well.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Kaleidoscope builder has its own port autodetection. Although fairly
robus, this mechanism sometimes fails under certain circumstances
on some Linux systems (e.g. Ubuntu 18.04).
As a workaround this change enables the variables DEVICE_PORT
and DEVICE_PORT_BOOTLOADER being predefined on GNU/Linux, e.g. as
DEVICE_PORT=/dev/ttyACM0 make flash
which will disable the port autodetection.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
mod
This adds some quotes to various paths used in Kaleidoscope's build system.
This fixes builds on msys2 that failed due to whitespaces in system paths.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
Many build systems allow C and C++ compilers to be specified
via environment variables C and CXX.
This commit enables this for kaleidoscope-builder.
Furtheron, on unixoid systems virtual builds are possible through a
command line similar to
CXX=<path to C++ compiler> C=<path to C compiler> ARCH=virtual make
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
This commit induces the following changes:
bin/kaleidoscope-builder
* ccache dummy compiler and executables are now generated in a way
that allows using the same CCACHE_WRAPPER_PATH for virtual and
non-virtual builds
* virtual builds are now triggered by either specifying the full FQBN with x86
as architecture or by defining ARCH=x86
etc/kaleidoscope-builder.conf
* COMPILER_PREFIX and COMPILER_PATH are now determined (if not predefined)
based on ARCH or FQBN
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
* Uses usbconfig to determine the Model 01's USB modem port.
* Works around incompatibe avrsize flags.
You need to be able to run usbconfig to flash the firmware from the
buildtools. This can be accomplished with appropriate groups and devfs
rules.
Requires gmake, perl, avrdude, and (probably) arduino18 from ports.
The version of avrdude in ports uses an avr-size command that doesn't
understand the -C or --mcu flags. From what I can tell, these flags
are uneccessary, as the size computed with them is the same as what
you get from adding up the appropriate segments from the standard
output of avr-size without any flags. However, since the size is only
informative, I've opted to simply check to see if the command
succeeded, and if not, output a string saying it could not be.
It would probably be better to:
* Determine appropriate flags based on build tools, or,
* Just not use the flags at all, and grab the .text, etc., segment
sizes from the standard output and add them up via `dc` for
display.
I've been using this toolchain to build successfully on FreeBSD 12 for
the Model 01 without issue. It should work with earlier versions of
FreeBSD as well.
Signed-off-by: Brian Cully <bjc@kublai.com>
We already support bootloaders that have the same vendor ID as the keyboard, but
a different product ID. We should also support bootloaders that have a different
vendor ID too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With the Atreus, we have a board that has a different max upload size depending
on what MCU is used. Until we figure out how to properly support that in the CLI
builder, default to using the first value. That's a reasonable approximation in
most cases.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of hardcoding the max program size, pick it out of boards.txt, like we
pick the device VID and PID.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Jesse Vincent
Gergely Nagy
Phil Hagelberg
Florian Fleissner
Dan Bjorge
Brian Cully