Regarding the missing features in clang format, have you considered opening feature requests for these with the clang devs?
Regarding a nxtool with multiple subcommands for things, such as style checking, this is an interesting idea that should be explored. My only concern is with the addition of developer-side dependencies. Whenever we add more required tools or languages on the developer's system, we potentially add friction that makes it harder for newcomer to adopt NuttX. It may not be avoidable, and in the long run, we're probably better off using existing well-maintained and well-adopted tools, which both Python and tree-sitter are, than to maintain custom tooling that tries to duplicate such functionality. Python is very likely to already be installed on developer machines, so is a good choice of scripting language. But we should still consider this carefully: Python is a language that morphs all the time and is always growing new features and syntax (like C++; the language has become huge). You have to know the whole language, because different developers who contribute to the scripts will know and use different parts of the language. Also Python has been known to change in non-backward-compatible ways, so we'll forever need to chase these. NuttX is implemented in C, so all of the NuttX devs know C, and aren't necessarily Python experts. Should we consider adopting tree-sitter but implementing nxtool in C? Cheers, Nathan On Mon, Mar 17, 2025 at 9:00 AM Matteo Golin <matteo.go...@gmail.com> wrote: > Hello, > > I have tried to make a clang format configuration to use, but I have the > same problem where there are a couple style items that clang format has no > options for. Things like enforcing lowercase hex or putting curly braces > indented on a separate line after static initializers. > > On Mon, Mar 17, 2025, 8:52 AM Mark Stevens <m...@thepcsite.co.uk> wrote: > > > Has anyone looked at using a custom .clang-format file to see if we can > > get close to the NuttX style? > > > > I’ve used this route in a couple of projects. I did have to compromise > on > > one or two rules as I could not get the exact format I wanted. I thought > > this was worth it as it saved me writing my own tool to do the job. I > then > > used a docker script to run the checks on every PR. > > > > Just wondering if it would save some effort. > > > > Regards, > > Mark > > ------------------------------------------- > > Mark Stevens > > Blog: blog.mark-stevens.co.uk > > > > > > > On 17 Mar 2025, at 11:31, Luchian Mihai <luchiann.mi...@gmail.com> > > wrote: > > > > > > Hello Nuttx, > > > > > > *--- Summary ---* > > > I've been in the habit of fixing small issues regarding nxstyle. > > > > > > One of the last conclusions drawn was that it does not tokenize the > file, > > > which leads to limitations in checking syntax. > > > Please check https://github.com/apache/nuttx/pull/15847 for further > > details. > > > > > > I am working on a new implementation of nxstyle using python and > > > tree-sitter for parsing and checking the source code. > > > Treesitter is getting more traction in the past years. Some editors are > > > making use of treesitter, such as zed, neovim, helix, and others. > > > GitHub uses if for code navigation > > > > > > https://docs.github.com/en/repositories/working-with-files/using-files/navigating-code-on-github > > > So, I think it may be a suitable solution for nuttx as well. > > > > > > This will take a lot of work, but you can track my progress at > > > https://github.com/LuchianMihai/nuttx/tree/nxtool. > > > Please feel free to add any suggestions you may see fit. > > > > > > *--- Questions ---* > > > > > > 1. > > > I've also set up the work for an new tool, calling it nxtool (at the > > time I > > > did not know that is not a new name/concept), > > > Mostly, it's a "boilerplate" to add more subcommands under a common > > command > > > called nxtool. > > > Currently only a single subcommand is present, checkpatch, equivalent > to > > > the present checkpatch.sh so basically call > > > *nxtool checkpatch file* > > > Now I've dug the mailing archive and found that nxtool, or similar > > projects > > > were proposed in the past, such as > > > https://gitlab.com/nuttx-upm/upm or > > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager > > > But both of them seem abandoned or not actively worked on. > > > I feel like I'm missing some info regarding the work I'm doing. > > > Why did the work stop, what was the issue with them? > > > I saw mentions of zephyr meta-tool west, and they weren't bad, or > against > > > tools alike. > > > > > > So my question basically is, what is the take of the nuttx community > > python > > > based meta-tool? > > > > > > 2. > > > Although I've already started investing time in this, I'm not sure how > > much > > > effort the nuttx community is willing to invest for enforcing > > > this custom coding style in favor of using clang-format and gnu style. > > > If I'm to add a new tool for enforcing nuttx coding style, I'd like to > > know > > > that there is no talk about deprecating this work. > > > > > > *--- Cosing words ---* > > > > > > As mentioned previously, please reply with any proposals, ideas, > thoughts > > > you have for such a tool, if any, > > > or any counter arguments you may have. > > > > >
