3 ms·

> This is a huge disparity from web development workflows where file watchers are prevalent—you save a file and instantly see the results of the change. > Pigw

> This is a huge disparity from web development workflows where file watchers are prevalent—you save a file and instantly see the results of the change. > Pigweed’s pw_watch module solves this inefficiency directly, providing a watcher that automatically invokes a build when a file is saved, and also runs the specific tests affected by the code changes. This drastically reduces the edit-compile-flash-test cycle for changes. Eh, no thanks. Web dev environments can get away with this because the turnaround time is so quick, but even a medium sized embedded C++ project can easily take minutes to build, plus 30+ seconds to download, even with a debugger. Please don't try to bring webdev workflows into the embedded space. This isn't javascript.

boris 7y ago
Yes, this struck me as a crazy idea for C/C++ development, embedded or not. What if you save something intermediate not meant to be compilable/testable? I for example have a deeply ingrained habit of saving my changes all the time going back to the floppy disk days when computers would regularly crash/freeze.
Espressosaurus 7y ago
Yeah, I'm trying to reconcile their objectives against a several minute build time (for just the deepest embedded target) up to a 15 minute build time (for the driver at the next level up) or even (god forbid) the top level target, which is a multi-hour build. And you want to kick that off every time I save one file? Are you nuts? And then pushing it to a target and testing it. Again, are you nuts? I work in the real world, with physical devices that can and will break if I misuse them. Blindly flashing my latest unfinished change is a great way to wreck equipment, even if it happens to compile. Maybe it makes sense for something like the MCU on a network switch. But it doesn't sound like something I want anywhere near any codebase I'm committing to. Handling the dependency management and environment is nice though. That part is absolutely a low-grade irritation that would be nice to get rid of.
deleted 7y ago
[deleted]
astatine 7y ago
Indeed! There is a certain thoughtfulness in a code/build/flash/test cycle in the embedded world, which Pigweed seems to see as a problem and tries to fix. I can (and often do) write code for many hours (sometimes days) without a flash/test cycle. I follow a very different process when I do a React based frontend and I don't think it is anywhere close to being suitable for embedded systems.

boris 7y ago

Yes, this struck me as a crazy idea for C/C++ development, embedded or not. What if you save something intermediate not meant to be compilable/testable? I for example have a deeply ingrained habit of saving my changes all the time going back to the floppy disk days when computers would regularly crash/freeze.

Espressosaurus 7y ago

Yeah, I'm trying to reconcile their objectives against a several minute build time (for just the deepest embedded target) up to a 15 minute build time (for the driver at the next level up) or even (god forbid) the top level target, which is a multi-hour build. And you want to kick that off every time I save one file? Are you nuts? And then pushing it to a target and testing it. Again, are you nuts? I work in the real world, with physical devices that can and will break if I misuse them. Blindly flashing my latest unfinished change is a great way to wreck equipment, even if it happens to compile. Maybe it makes sense for something like the MCU on a network switch. But it doesn't sound like something I want anywhere near any codebase I'm committing to. Handling the dependency management and environment is nice though. That part is absolutely a low-grade irritation that would be nice to get rid of.

deleted 7y ago

[deleted]

astatine 7y ago

Indeed! There is a certain thoughtfulness in a code/build/flash/test cycle in the embedded world, which Pigweed seems to see as a problem and tries to fix. I can (and often do) write code for many hours (sometimes days) without a flash/test cycle. I follow a very different process when I do a React based frontend and I don't think it is anywhere close to being suitable for embedded systems.