@MrKevinWeiss @kaspar030 In regards to the "one board per line" vs. "80 characters per line" question, I favor one board per line because it results in much cleaner diffs. For example, in the 80 characters per line case, if I wanted to change the first board in a list, this would likely change all following lines of the list in the diff.

I agree with one line per list item in general for the improved readability in the diffs.

Should we first merge #9965? In master not everything is structured in the same way so I had to manually edit some things. I only stalled because nobody seemed to want one item per line.
Just pay attention to cbor BLACKLIST, libfixmath_unittests BLACKLIST and some other ones that are not alphabetical.

Hmm, #9965 doesn't seem to be a PR. Did you mean #9983?

I ran my script against the PR with your changes from #9983, and my script would make some additional changes to board lists that fit on one line. You've left them as one line entries, whereas my script is strict in that it only allows one board per line no matter the length.

Either way I see no harm in merging that PR first :D

#9983 is right, don't know where I got that number from...

Ya a few that I missed (one liners). Hopefully I can get this pushed through if this is the way we want to go.

Looks like we should merge your script with all the changes that it does. I can do a review when you are ready!

Tiny formatting changes that I would like to discuss:
Putting the first item on a separate line from the variable, ending the last line with a backslash, and adding an empty comment line below would make the whole list homogeneous, no special cases for any item in the list.

so instead of:

BOARD_INSUFFICIENT_MEMORY := arduino-duemilanove \
                             arduino-uno \
                             nucleo-f031k6

we would get:

BOARD_INSUFFICIENT_MEMORY := \
  arduino-duemilanove \
  arduino-uno \
  nucleo-f031k6 \
# end BOARD_INSUFFICIENT_MEMORY

Okay, the script now formats all three variables. A couple of corner cases popped up, however:

Handling comments after a specific board would make the script quite a bit more complex, so I'm kinda hoping there's a way around it :D In such a case I suppose it'd be easy to just put it on the preceding line:

# tests/socket_zep/Makefile:

BOARD_WHITELIST = native    # socket_zep is only available on native

These here are a tad more complicated I suppose:

# tests/mpu_stack_guard/Makefile:

BOARD_WHITELIST += arduino-due      # cortex-m3
BOARD_WHITELIST += arduino-zero     # cortex-m0plus
BOARD_WHITELIST += cc2538dk         # cortex-m3
BOARD_WHITELIST += cc2650stk        # cortex-m3
BOARD_WHITELIST += ek-lm4f120xl     # cortex-m4f
BOARD_WHITELIST += f4vi1            # cortex-m4f

But could maybe be formatted as:

 # cortex-m3
BOARD_WHITELIST += arduino-due \
                   cc2538dk \
                   cc2650stk

# cortex-m4f
BOARD_WHITELIST += ek-lm4f120xl \
                   f4vi

Finally, there are cases where the list is terminated with a line such as the following, presumably to have a cleaner diff in case the last board is modified. Here the question is if we'd want to introduce this everywhere, or remove it where we're currently doing it:

# examples/filesystem/Makefile:

BOARD_BLACKLIST :=  chronos \
                    msb-430 \
                    msb-430h \
                    telosb \
                    wsn430-v1_3b \
                    wsn430-v1_4 \
                    z1 \
                    #

If we manually fix the corner cases would that make things easier. From what I saw there aren't that many of them and hopefully once they are fixed they stay fixed. At least that is what the review process should enforce.

True, my question was also along the lines of "do we need these corner cases". But I suppose that is a "no", meaning the script would simply not allow comments on board list lines?

@gebart I'm fine with that, I just tried to adapt the script to the most common way currently in use. Who would need to be involved in a discussion to make more serious modifications to the current format?

I also found this one BOARD_PROVIDES_NETIF
same issues

Yep, I've put some more work into this, but moving the variables around in the Makefile has a bunch of annoying corner cases that I need to deal with, so its not yet ready for prime time. I'll try to get it done next week once I'm back from vacation :D

@x3ro Anything I can do to help the progress?

@x3ro Anything I can do to help the progress?

It's mostly done, I need to find time to clean it up. Should be feasible sometime this week.

@MrKevinWeiss @jcarrano changes made and applied to #10130

I like the output, if the inline comment and multiple += instead of := / are handled manually (as there are only two cases) then I think at least everyone can agree on the output of it.

@x3ro ping

As a worst case I would like #10130 fixed and merged.

Apologies for the delay, I haven't had time and motivation to pick this up in the last weeks, but I still want to get it merged. I'm aiming for before / at the next Hack 'n' Ack.

@x3ro Yup, just let me know if you need something from me!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

I would still like to see this or something like this in. If you don't want it I can take over?

Yep I haven't been able to work on it in quite a while. I'll be at Hack'n'Ack this month, and will do my best to get it merged on that day.

So I've rebased and gone over the output again. The following seem to be the only files that are not formatted correctly yet:

• tests/cortexm_common_ldscript/Makefile (many += to append to list)
• tests/driver_cc110x/Makefile (many += to append to list)
• tests/mpu_stack_guard/Makefile (many += to append to list, comments)
• tests/sys_crypto/Makefile (many += to append to list)
• tests/unittests/Makefile (many += to append to list)

I'll try to come up with a good fix for inline comments and propose to then go ahead and merge this PR, subsequently update #10130 and get that merged as well.

Very nice, thanks. This is back on my radar!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.