Loading ...
Sorry, an error occurred while loading the content.

5584Re: [nuttx] Thinking about porting my Pico BASIC (phasic) to NuttX

Expand Messages
  • spudarnia
    Mar 26, 2014
    • 0 Attachment
      Hi, Ken,

      > You know, I said the biggest portion of porting uC BASIC would probably be adding the platform independence layers, but now I'm thinking maybe the biggest part will be adapting to the NuttX coding standard!  I wrote all this code last year pre-April (i.e. before I even knew NuttX existed).
      > What's your take on formatting when pulling in pre-existing BSD-licensed code into the source tree?  :)

      In the long run, I think that all of the code in the nuttx/ and apps/ directories should follow the same coding standard.  I don't know how large this body of code is, but these are the things the occur to me.

      Option 1:  Check if a non-compliant version and let it mature and converge on the coding standard over time.  I don't have any problem with this.

      If you want to go this way, then I would think the minimum pre-checkin requirement would be:  (1) Make sure that there are BSD headers all all of the files, and (2) run the files through one of the formatting tools.  That would get us 90% of the way there anyway.

      I am aware of two formatting tools:

      a. There is nuttx/tools/indent.sh.  It gets you most of the way there but does do a few strange things.  See the comments at the top of the indent.sh file.

      I find that it does a better job if you first strip tabs and carriage returns from the file.

      b. Lorenz Meier also provided a formatting method that might work better.  That is in this email: https://groups.yahoo.com/neo/groups/nuttx/conversations/topics/5425.  Lorenz suggested:

      astyle \
      --style=gnu \
      --indent=spaces=2 \
      --indent-cases \
      --indent-switches \

      I will add this to the tools/ directory tool.

      Option 2:  You could make the interpreter a separate module under misc/ that gets installed into the NuttX source tree during configuration (perhaps via symbolic links?).  There are examples in misc/drivers/INSTALL.sh, misc/pascal/nuttx/INSTALL.sh, and misc/uClibc++/install.sh.  As a separate module, you can use whatever coding style that you want.

      I would opt of Option 1 (pardon my redundancy).  I would not think that adding the headers and passing the code through a tool, and verifying the result would be a big effort.


    • Show all 17 messages in this topic