mrburnette wrote: ↑Tue Jun 15, 2021 11:36 pm
ag123 wrote: ↑Tue Jun 15, 2021 3:45 pm
...
there are probably 'better' build automation solutions (normally consider 'part' of IDE), but i've not explored them as well...
WHY? I just do not understand.
History: The "duino" in STM32
duino.com has always been representative of Arduino and the design/implementation of the underpinnings to allow the ArduinoIDE to create a somewhat seamless environment for developing STM32 code, link, and uploading for STM32 boards.
Everyone should know (or should be told) that ArduinoIDE is a non-professional development system: capable of generating professional code but within a somewhat limiting IDE.
IMO: if people do not like the Frankenstein'ish JAVA-based & OS-centric scripting ArduinoIDE system, they have numerous options: many better but with perhaps a learning curve. The limitations of Arduino IDE are many, but forum posters who complain about issues outside STM's cores are beating a dead horse ... even Arduino is moving to a completely different architecture for the 2.x IDE which is in beta and significantly slower at this time likely due to debugging code and logfiles.
+1 but literally, the notion me needng of a 'build automation' solution, did not start with the arduino ide. Rather i preferred using eclipse due to the syntax highlighting and code/item reference jumps - the reference jumps saves *a lot* of time searching for codes. unfortunately, without something like
sloeber, patching up all the includes, defines and compiler options manually in eclipse is *extremely tedious*, creating a new stm32duino 'project' takes a day just to patch up all that, the last time i counted, there could nearly be a hundred or so includes, defines and compiler options and multiply that by 2 sets (debug and release). since switching to makefile builds, it becomes simply copying the makefile over and editing the makefile in the new project.
But with eclipse, even
sloeber isn't fully 'compatible' with stm32duino, some PRs there are needed there to make things work well. the closest 'out of box' build automation solution for now is
arduino-cli. however, due to its base around the board manager, libmaple (roger's) core would need some adaption to kind of use it. the dislike i've about the board manager design is that the use of remote repositories are implied. this is very good for 'commercial' implementations, but that public domain ones would see some challenges as it implies that the remote repositories need to exist and be online.
i think things like gradle is a better and significantly more flexible build automation solution, but for now arduino-cli is the de-facto built automation solution and given all the efforts Arduino and the community has put into it. one of the more difficult parts is being cross platform, this leaves much fewer choices and that arduino-cli is developed with cross-platform being implied as a feature. 'build automation' matters as it separates the concerns of the 'gui' or rather 'ide' and 'build', this is so that you can have different 'ide's but a uniform 'build automation' toolchain, i think the idea sticks and is probably the motivation behind arduino-cli.
oh and about that i simply type *make*
