-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build system woes and ideas #887
Comments
Having had a good nights sleep pondering about this, I have a few things in mind now, that would be amazingly nice to have, and all of which are quite simple to do with a thin wrapper around
|
I'm not knowlegeable enough to know what it would take, but my hope is that this issue will be fixed. This certainly isn't a limitation that was added intentionally.
Arduino CLI supports defining the FQBN via a sketch.json metadata file placed in the sketch folder:
It's true that |
Oooh, nice! This works like a charm, thank you!
To be honest, requiring a port is fine. We have the tooling to discover which port we need to specify, so |
Had a quick talk with @obra this morning too, and he suggested an alternative to symlink-farming the compilers: just ship a set with our virtual platform, the same way Arduino does for AVR and SAMD. That way, we never have to care about where compilers are, nor about subtle differences, nor anything like that. We'll just package them up, and we're good to go. Inspired by this, I converted my own sketch to use |
I'm not at all familiar with your project, so forgive me if I provide irrelevant information. So you can configure |
Much appreciated, |
Way back when, we had #497, with the goal of rebuilding
kaleidoscope-builder
, which was concluded with us not wanting to rebuild it - we'd rather replace it. Now, the question is: with what?We basically want two major things: compile sketches, and flash them. In addition that, we want to be able to run tests on virtual, simulated hardware. This latter is basically compiling for the virtual arch, and then running the result.
The simplest way would be to use
arduino-cli
, which is official, and supports pretty much all we want and need, and we can wrap it very, very thinly, if need be. It has a number of incompatibilities compared toarduino-builder
: it requires the sketch name to be the same as the containing directory, which is sometimes a bit awkward, but easily solvable. It also lacks support for passing certain type of compiler flags, namely#define
s that have a string argument (see here). Not an issue for the sketches we ship, but we have a few custom sketches by users that do make use of string defines. This can be worked around by prepping a header file first, and putting the defines there, but that's a bit more work on the part of the user.But, stepping back: as a user, I would like to be able to:
kaleidoscope-builder compile examples/Devices/Keyboardio/Model01
, and have it do the right thing. I also would like to be able tokaleidoscope-builder compile examples/Devices/Keyboardio/Atreus
, and have that work out of the box as well, withupload
(orflash
) likewise. For this, we need to figure out the arch of a sketch. Or we may require the user to specify that:kaleidoscope-builder compile --board keyboardio:avr:model01 examples/Devices/Keyboardio/Model01
- but that's quite a handful.Flashing is the harder part, too, because we have a number of complicated scripts that help us find the right port, which we can't even integrate into the arduino system, because
arduino-cli
simply requires us to give it a port. So we'd need a wrapper for that.In short, it looks like
arduino-cli
could be a reasonable replacement. We'd get rid of a whole host of custom code that barely works. What we do need to pay attention to, is tool paths:arduino-cli
will, by default, use the tools specified inboards.txt
andplatform.txt
. But sometimes, we want to override those - that must remain possible.The text was updated successfully, but these errors were encountered: