On Wed, Mar 19, 2025 at 9:58 AM Luchian Mihai <luchiann.mi...@gmail.com> wrote: > Hello all, > First, a few conclusions I've drawn: > * Keep indent checking fully decoupled, indent style may or may not change > in future. > * For the moment we'll keep gnu style. Code style change will have a big > impact over the code base. > * If it comes to change, Allman is the best candidate, this will not have > an significant impact on my work, changing an constant for braces indent > depth (this only applies for indent)
Maybe adhering to GNU will enable standard tools and bring minimal change. But there is a big resistance, so probably updating tools/nxstyle is the way to go.. using C as it is right now. NuttX is quite conservative as you can see. Most of us can work with different code styles while we care most about functionality and long-term maintenance :-) Luchian maybe you could focus on different area where currently manpower is more desired.. like adding drivers to missing peripherals in existing MCUs, updating documentation, or adding missing CMake stuff if you prefer to support more modern tools? > Second, some would avoid python, let's discuss programming language: > I'll add a few key points for this discussion: > * Zephyr is using python for its meta-tool, west. > * Mynewt is using go for its meta-tool, newt > * Do nuttx need/want a similar meta-tool > * There are already python scripts in our tooling, maybe worth > standardizing them. > * If it comes to not using python i'll insist on using rust, personal take, > I do not want to handle strings using c. There were discussions like this before. We do not want this kind of meta-tool. No additional programming languages frameworks and dependencies to setup things. We want to keep things absolutely minimal and Unix aligned with independent but cooperating building blocks as it is right now. Including CMake and Python was exception here rather than a rule :-) How would you like to standardize python scripts? Right now these are independent tools, so if anything that uses them updates then a tool update goes along together. If you standardize them into a meta-tool then this meta-tool will require additional work for maintenance and updating one thing may break other things and we want to avoid that. I guess small building blocks are here by design :-) Rust is supported by nuttx-apps but only as option for users interested in it. It is their burden to have all dependencies built and installed. No one else is impacted. But having rust as basic dependency just to setup things is a strong no-go here. Imagine building whole rust ecosystem on a small embedded system with limited resources where packages are not provided (i.e. rPI0). I had this problem with pyOCD+CMSIS-Pack-Manager, other folks too, so the dependency was removed as default after feedback of the community. We recently did tests of automated distributed testing on rPI0 and it was working fine. Introducing Rust as basic setup dependency would make things a lot more complicated and time consuming, maybe even a blocker on some platforms, we want to avoid that. I was recently on a hands-on STM workshop. I did quick port NuttX to a new MCU under 10 minutes. While the workshop was aimed at Zephyr and (~30) people could not even git clone the repository to start working. It was too big to fetch at once by that many people. Minimalistic approach of NuttX has its benefits :-) > Let's hear the community take on this subject. Always good to discuss :-) Have a good day folks :-) Tomek ps/2: Is this a some sort of global race where winner changes as many lines of code without actual change of the functionality / without adding new functionality / breaking existing functionality? Are people paid per changed line of code right now? Maybe "progress" is measured by changed lines of code or PR amount? :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
