3 ms·
I disagree. Getting started really really quickly would be 1. sudo apt-get install gcc-arm-none-eabi 2. make Instead, we have this extreme tool-bloat wher
by pawadu 10y ago
I disagree. Getting started really really quickly would be
1. sudo apt-get install gcc-arm-none-eabi
2. make
Instead, we have this extreme tool-bloat where a tiny tiny executable is produced using python, python-setup, cmake, libffi, libssl, clang, pip and finally yotta in addition to GCC and binutils (which is really all you should need).
Can someone please explain to me this new trend of in-house tools and tool-bloat?
- IshKebab 10y agoOk now how do you change targets to a different board (e.g. nRF51-DK), and have the LEDs and USB serial still work with no changes? How do you install the BLE dependencies? How do you use apt-get on Windows? I agree it could be easier and also agree that Python and CMake are the wrong tools for the job, but frankly apt and make would be worse. At least they seem to have designed the module description system fairly nicely so it could potentially be rewritten with a better architecture in future.
- pawadu 10y agoWhat you mention is a board/library issue not a tool issue. But looking at how the AVR community has solved this, it is certainty solvable at "apt-get level". Also, apt-get works just fine on Windows 10 nowadays :) edit: For the record, there is nothing wrong with a new tool system. But adding layers of layers of complexity and dependencies to something simple just because you couldn't care to learn to do things the standard way only creates problems for you and your users.