SDK headaches

[jacoffey3]

Main current items:

• Windows environment in the SDK leaves something to be desired. You have to constantly transfer files as part of the regular process.
• Debugging isn't possible for Linux except through console output.

Possible solutions:

• No idea for Windows. The route of working on a remote server seems to work okay for now...but I'm really not sure how to solve it in another way.
• Upgrade to work with Linux through a remote GDB server.

Larger questions:

• Should we be fostering development directly on the board rather than in the SDK?
• Should the vagrant be an emulation of the KubOS Linux environment that you develop in until you're ready for hardware?
• Would this make Hopper an AWS-like environment where you're getting to log in directly to the flight computer?

[CatGarab]

"Should we be fostering development directly on the board rather than in the SDK?"

• Meh. I'm not sure of the benefit. You lose the ability to use an IDE for any target that doesn't support ethernet.

"Should the vagrant be an emulation of the KubOS Linux environment that you develop in until you're ready for hardware?"

• We use the vagrant to build everything, including KubOS Linux. I feel like stripping down the vagrant to make it an emulation would require us to come up with some other system/image to handle our builds. That being said, if we want a build system and then a separate emulation system, QEMU is still a thing...

[plauche]

"Windows" - Agreed - the experience doesn't sound very pleasant right now. One option would be to create a new vagrant box specifically for Windows development. It would be based on our current SDK, but would layer on a Linux GUI environment. Users would still have to work entirely in the VM, but it would at least have everything needed inside of it.

"Debugging" - It is definitely possible to run a gdb server on board and connect to that either over UART or ethernet. This would allow us to run gdb locally (or in an IDE) and debug what is running on board. We need two commands: kubos run and kubos debug. Run would execute a binary on board and display the output. Debug would start up the gdbserver, attach it to the binary and start up gdb locally for debugging. These commands may already exist in some form but only work for RT or local testing.

"Should we be fostering development directly on the board rather than in the SDK?" - Development meaning testing? I don't think this is an either/or thing. Local testing allows developers to move quickly and easily test if changes have broken things across multiple binaries/libraries. On board testing gives you access to the actual hardware and is a must for final verification.

"Should the vagrant be an emulation of the KubOS Linux environment that you develop in until you're ready for hardware?" - No, ideally we would have two individual local environments, one for compiling and one for testing. The vagrant box works just fine for actual building. We are currently (mostly) able to test binaries in the vagrant box because it is also linux. However we really should use an environment produced by our buildroot setup so that the kernel/libc/etc versions match our on-board systems.