3 ms·
You have to do that work anyway... Why not encode it in your build system? (Admittedly I have never tried this with a modern build system. My real world appro
by bjackman 3y ago
You have to do that work anyway... Why not encode it in your build system?
(Admittedly I have never tried this with a modern build system. My real world approach for that would be a janky phony rule in a Makefile, with a bunch of MAKE_VARS the user has to set on the cmdline/in the environment to set up the toolchain/serial port etc. But in principle I have always believed it should be possible to make this process as easy as compilation)
- reactordev 3y agoAre those vars discoverable? As in can you infer what they should be? If you can’t, or are building for all unknown possibilities, wouldn’t it be safer to enumerate known var values to perform that? Why must everything be explicit? Wrap it all up into one var. cmake -DBUILD_FOR=esp32 . Then provide your own little runtime.sh. For other languages and build systems, a runtime run sourcefile is the easiest way to get someone going, leave the edge cases out. Just get it running so they can hack on it.
- bjackman 3y agoNo, you have to manually document them and then the docs go out of date and you can't realistically set up CI for this little runner script so certain use cases get broken and blah blah blah and it sucks! Same for runtime.sh. This is why the 'runtime run source' is so useful! I'm totally on board with it. I just don't think we need one implementation per ecosystem. One runner per project (the 'make run' approach) is worse than one per ecosystem, which is in turn worse than just having one for everything!