Libdragon CLI 2.0

[rasky]

Given experimentation with the CLI prototype in Go, I would say that it would be great if the official tool grew these features:

• Must be able to ship as a native application on Windows, with no separate NPM installation.
• libdragon init that sets up a libdragon skeleton project, vendor libdragon and downloads the toolchain
  • toolchain download via docker or other means (eg: zip + unpack). Could have an option to also skip altogether (if user wants to use their own toolchain).
  • libdragon vendoring via subtree
  • libdragon vendoring via submodules. People are opinionated on this, I think the best is to support both
  • the project skeleton should come with a makefile that builds Libdragon + example ROM.
• libdragon make should imply start whenever required. In general, I would phase out start / stop as low-level / manual commands not required in most cases
  • It must be very fast. It should optimistically execute docker just once hoping that everything will work, and then fallback to starting the container if it's not starting, then falling back to creating the container if it doesn't exist for the current repo. The correct container (per-repo) must thus be optimistically cached.
• Should automatically create one container per project, transparently.
  • The container should mount the top-level git directory (if used on a git repo)
• All commands should respect the current working directory, so that you can run make in subdirs
• libdragon update should update both the libdragon vendored copy (respecting the chosen vendoring system) and the toolchain.
• libdragon exec as a quick way to launch things in the container, such as the libdragon tools.
  • it should support interactive tools (forward stdin/stdout/stderr).
  • Since libdragon tools will be compiled as part of the local libdragon copy, there must be a way to exec them without having to reinstall them every time the container is lost. Possibly launching them from the build directory or something like that.
• libdragon disasm to disassemble the current elf binary (to be automatically searched in build directories and recursively, with an option to disambiguate if the project builds more than one ROM).
  • This should also support disassembling only a specific symbol
• Command line help for all commands, and in general accurate user-friendly error messages (and output)
  • A verbose mode that shows everything that is run is very useful for debugging

[anacierdem]

I have prepared a pre-release here. It is not being released to NPM yet. As we have git in the container the user does not have to have git and we use it from the container when necessary. I plan to release this with this feature set as it is already much better. Most probaby I will first work on subtree support next. We keep persistent libdragon project info in a .libdragon folder.
I have checked what is implemented as of now with a few notes;

• There is no skeleton project yet
• libdragon make is implemented to be fast, but there still will be scripting overhead, so there is no 'very fast' guarantee yet.
• It is possible to do libdragon init at an NPM project's or git root

Since libdragon tools will be compiled as part of the local libdragon copy, there must be a way to exec them without having to reinstall them every time the container is lost. Possibly launching them from the build directory or something like that.

• Currently I invoke build.sh which start with a clean step. Once we set things up better at main repo, I think we can solve this as the mounted file system is persistent.

Other ideas;

• libdragon bash to start an interactive shell session
• libdragon clean to clean up the project
• Use current folder name as container name when possible (See Try how docker compose works for this usecase #50)
• Add a version action

[rasky]

libdragon bash to start an interactive shell session

I usually do libdragon exec bash with my tool

[anacierdem]

toolchain download via docker or other means (eg: zip + unpack). Could have an option to also skip altogether (if user wants to use their own toolchain).

This is very easy to do with docker load which an advanced enough users wouldn't mind doing themselves, so I'm assuming this already exists.

Since libdragon tools will be compiled as part of the local libdragon copy, there must be a way to exec them without having to reinstall them every time the container is lost. Possibly launching them from the build directory or something like that.

If we decide to go towards docker compose this almost becomes trivial to implement. Still possible with the current architecture but will require some housekeeping. I will work on this later -> #53

Closing this issue 🎊