Skip to content

Apply auto-formatting as implemented in PR #10111#12577

Closed
x3ro wants to merge 1 commit intoRIOT-OS:masterfrom
x3ro:pr/apply-board-list-formatting
Closed

Apply auto-formatting as implemented in PR #10111#12577
x3ro wants to merge 1 commit intoRIOT-OS:masterfrom
x3ro:pr/apply-board-list-formatting

Conversation

@x3ro
Copy link
Copy Markdown
Contributor

@x3ro x3ro commented Oct 26, 2019

Let's get PR auto-formatting merged! 🎉 This replaces #10130 in the hopes of having a short discussion/review and then being able to merge!

Once this is merged I'd then push forward and get #10111 wrapped up, followed by a PR that integrates it into the build system.

🚂

@x3ro x3ro added Area: build system Area: Build system Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Oct 26, 2019
@x3ro x3ro requested a review from MrKevinWeiss October 26, 2019 18:00
@x3ro x3ro self-assigned this Oct 26, 2019
@MrKevinWeiss
Copy link
Copy Markdown
Contributor

It would seem we have to coordinate since these files change so often. I will check through everything now then we should move fast after you rebase.

Copy link
Copy Markdown
Contributor

@MrKevinWeiss MrKevinWeiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good generally, I would like to replace all BOARD_* += \ with BOARD_* := \, since it only evaluates once it could be faster (though I doubt it would have that big an impact). This means that there can only be one := since additional := overwrites previous values. So maybe just move all comments to the top or bottom then everything will only have one assignment.

Another thing that I would like to run some tests on is moving the include $(RIOTBASE)/Makefile.include to the bottom. Some makefiles will have orders changed, though I don't think it will have any impact it would be nice to just confirm it. I will look into how to achieve it.


USEPKG += ubasic
USEMODULE += ubasic_tests
USEMODULE += printf_float
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmmmm?

Comment on lines +25 to +27
# arduino-mega2560: builds locally but breaks travis (possibly because of
# differences in the toolchain)
# The MSP boards don't feature round(), exp(), and log(), which are used in the unittests
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can move all comments to the bottom since everything so far isn't ordered anyways?

Comment on lines +28 to +36
BOARD_BLACKLIST += \
chronos \
msb-430 \
msb-430h \
telosb \
wsn430-v1_3b \
wsn430-v1_4 \
z1 \
#
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also combine these then to help push the idea of always using := instead of sometimes having +=

feather-m0 \
opencm904 \
spark-core \
#
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move the comment to the top and combine so we can use :=

@MrKevinWeiss
Copy link
Copy Markdown
Contributor

I don't want to drag it on and these things can be attended to in follow-up PRs when it is easier to manage but if it isn't a problem it would be nice to have.

smlng
smlng previously requested changes Oct 29, 2019
Copy link
Copy Markdown
Member

@smlng smlng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NACK, kindof - with #9081 merged we should use that to get rid of BLACK listing and in theory the whitelists, too.

@smlng
Copy link
Copy Markdown
Member

smlng commented Oct 29, 2019

so no need for reformatting

@x3ro
Copy link
Copy Markdown
Contributor Author

x3ro commented Oct 29, 2019

Mmh, I'm honestly not super invested in this change anymore. If it's foreseeable that all of the black- and whitelists will disappear soon then sure, maybe there's no need to merge this. I cannot say I'm able to gauge how long the transition to feature lists will take for all boards.

What do you think, @MrKevinWeiss?

That being said, should we then also abandon #10111? Or would we want to auto-format FEATURES_* lists the same way it formatted black- and whitelists. What about BOARD_INSUFFICIENT_MEMORY?

@smlng
Copy link
Copy Markdown
Member

smlng commented Oct 30, 2019

@x3ro, to me #10111 is still valid bc there will be corner-cases where we currently still need some kind of board list. What I wanted to point out here is, that before we reformat existing black/white lists we should look which of these can easily be replaced by using the feature required or blacklist method.

Which means this PR is not completely invalid but not all changes are necessary or at least we can/should avoid changing them twice in short succession.

@x3ro
Copy link
Copy Markdown
Contributor Author

x3ro commented Oct 30, 2019

at least we can/should avoid changing them twice in short succession.

I think I disagree with this, i.e. I don't see much of a problem with changing them in short succession, and there's always the risk that a supposedly easy change (e.g. removing the blacklists) takes longer than expected, thus in this case also delaying this here pull request.

That being said, I don't feel strongly about it and thus will leave this open until the relevant changes on the black- and whitelist side are done, so that I can update. Please ping me here in this issue once this is done @smlng or @aabadie or whoever is spearheading that task :)

@MrKevinWeiss
Copy link
Copy Markdown
Contributor

I would like this done sooner than later. It should be pretty simple clean everything at least. Additional cleanups should benefit from working with cleaner makefiles.

Alternatively, we can just push the formatting script as a tool and not with the CI and let whoever wants to get the makefiles up to a standard with all the features grouped take care of it. Then once everything fits the script invoke it with murdock.

@MrKevinWeiss
Copy link
Copy Markdown
Contributor

ping

@smlng
Copy link
Copy Markdown
Member

smlng commented Nov 21, 2019

I think we need consensus here which way to go first, either this PR or postpone until board blacklists have been replaced by proper feature specs.

@smlng smlng dismissed their stale review December 9, 2019 13:41

unresolved, wait for author

@x3ro
Copy link
Copy Markdown
Contributor Author

x3ro commented Dec 27, 2019

What is the state on the proper feature specs?

@miri64
Copy link
Copy Markdown
Member

miri64 commented Jun 25, 2020

What is the state on the proper feature specs?

They are in. Care to rebase / rework this?

@stale
Copy link
Copy Markdown

stale bot commented Dec 28, 2020

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.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Dec 28, 2020
@stale stale bot closed this Jan 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: build system Area: Build system CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR State: stale State: The issue / PR has no activity for >185 days Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants