A couple of things to bear in mind: - Perfection is the enemy of good - Would you rather maintain a tool for styling or work on Apps/OS code?
I agree that as it stands, clang-format does not always allow enforcement of the exact style we would like but if it is nearly there is it worth looking at the style and possibly changing? Somethings could be enforced at PR time, the one that was mentioned is hex constants. So clang-format does not do that but it does not cause a failure either. So if 95% of the stuff is there, then is it good enough with manual intervention at PR/merge time? If we have a new tool then someone has to maintain it which is great if you have a group of people who are passionate about tools. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 17 Mar 2025, at 14:00, Peter van der Perk <peter.vanderp...@nxp.com> wrote: > > The main issue I was facing with clang-format was the indentation with NuttX > BreakBeforeBraces style see > https://github.com/llvm/llvm-project/issues/44188 > > Regards, > > Peter > > -----Original Message----- > From: Nathan Hartman <hartman.nat...@gmail.com > <mailto:hartman.nat...@gmail.com>> > Sent: Monday, March 17, 2025 2:39 PM > To: dev@nuttx.apache.org <mailto:dev@nuttx.apache.org> > Subject: Re: [PROPOSAL] New nxstyle tool roadmap > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> github.com >>>> <http://github.com/>%2Fapache%2Fnuttx%2Fpull%2F15847&data=05%7C02%7Cpeter.va >>>> <http://7cpeter.va/> >>>> nderperk%40nxp.com >>>> <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc >>>> 2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632496788%7CUnknown%7CTW >>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z >>>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hULCYTu4Wc >>>> TAeojjtlaWZlKrEi0hdM7WBEWYVBGlWu0%3D&reserved=0 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 >> <http://github.com/>%2Fen%2Frepositories%2Fworking-with-files%2Fusing-files%2Fn >> avigating-code-on-github&data=05%7C02%7Cpeter.vanderperk%40nxp.com >> <http://40nxp.com/>%7C5 >> 23719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 >> %7C0%7C638778155632522235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >> 3D%7C0%7C%7C%7C&sdata=pqiaN5mq4Vkfftwe8G2F1PsmxFXDw08XkVsAx%2BjkjqI%3D >> &reserved=0 >>>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> gitlab.com >>>> <http://gitlab.com/>%2Fnuttx-upm%2Fupm&data=05%7C02%7Cpeter.vanderperk%40nxp >>>> .com%7C523719ea66ff4c72fe8d08dd65591eda%7C686ea1d3bc2b4c6fa92cd99c >>>> 5c301635%7C0%7C0%7C638778155632554445%7CUnknown%7CTWFpbGZsb3d8eyJF >>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CPkRSYKGw1uEmABoXKTyelEO >>>> axSV%2BAhdAIRe%2Fq7rhFE%3D&reserved=0 or >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> gitlab.com >>>> <http://gitlab.com/>%2Fnuttx_projects%2Fnuttx_workspace_manager&data=05%7C02 >>>> %7Cpeter.vanderperk%40nxp.com >>>> <http://40nxp.com/>%7C523719ea66ff4c72fe8d08dd65591eda%7 >>>> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638778155632569907%7CU >>>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI >>>> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata >>>> =HTL0lm3o1zZrGCjDRAWUGimzePcoD4ivySqmpOoK22c%3D&reserved=0 >>>> 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.
