-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[TRACKING] buildsystem: introduce "make rawterm" #11099
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
9679d05
53800ba
3849f8a
990020e
7a2e825
086480a
0ad9540
88e14f6
8d74a1b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,11 +16,29 @@ RIOT_TERMINAL ?= pyterm | |
| ifeq ($(RIOT_TERMINAL),pyterm) | ||
| TERMPROG ?= $(RIOTTOOLS)/pyterm/pyterm | ||
| TERMFLAGS ?= -p "$(PORT)" -b "$(BAUD)" | ||
| else ifeq ($(RIOT_TERMINAL),socat) | ||
| SOCAT_OUTPUT ?= - | ||
| TERMPROG ?= $(RIOT_TERMINAL) | ||
| TERMFLAGS ?= $(SOCAT_OUTPUT) open:$(PORT),b$(BAUD),echo=0,raw | ||
| else ifeq ($(RIOT_TERMINAL),rlwrap) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is unrelated to supporting |
||
| TERMPROG ?= $(RIOT_TERMINAL) | ||
| RLWRAP_PROMPT ?= -pPurple -S 'RIOT $$ ' | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why even adding a prompt ? |
||
| RLWRAP_FLAGS ?= -a -C RIOT-$(BOARD) | ||
| TERMFLAGS ?= $(RLWRAP_PROMPT) $(RLWRAP_FLAGS) $(RAWTERMPROG) $(RAWTERMFLAGS) | ||
| else ifeq ($(RIOT_TERMINAL),picocom) | ||
| TERMPROG ?= picocom | ||
| TERMFLAGS ?= --nolock --imap lfcrlf --baud "$(BAUD)" "$(PORT)" | ||
| else ifeq ($(RIOT_TERMINAL),custom) | ||
| # Do nothing. This name is reserved so that TERMFLAGS does not get | ||
| # set if the user wants to override TERMPROG. | ||
| endif | ||
|
|
||
| RIOT_RAWTERMINAL ?= socat | ||
| ifeq ($(RIOT_RAWTERMINAL),socat) | ||
| SOCAT_LOCAL ?= STDIO,icanon=0,echo=0,escape=0x04 | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With these options I'm still getting line buffering. |
||
| SOCAT_REMOTE ?= open:$(PORT),b$(BAUD),echo=0,raw | ||
| RAWTERMPROG ?= $(RIOT_RAWTERMINAL) | ||
| RAWTERMFLAGS ?= $(SOCAT_LOCAL) $(SOCAT_REMOTE) | ||
| else ifeq ($(RIOT_RAWTERMINAL),picocom) | ||
| RAWTERMPROG ?= picocom | ||
| RAWTERMFLAGS ?= --nolock -q --imap lfcrlf --baud "$(BAUD)" "$(PORT)" | ||
| else ifeq ($(RIOT_RAWTERMINAL),custom) | ||
| # Do nothing. This name is reserved so that TERMFLAGS does not get | ||
| # set if the user wants to override TERMPROG. | ||
| endif | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you also use simply expanded variables
:=here and in all following cases below? There's no need for recursions as it appears to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment we are trying to do the opposite: remove instances of
:=where it is not needed.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting .. as far as I know you usually remove instances of
=, where it is not needed (: maintaining recursively expanded variables is complex and can lead to hard-to-debug problems. Imagine someone replacespytermwith a function or a variable in the future, but keeps the=..What's the motivation for choosing recursive assignments over simple assignments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:=has some disadvantages::=depends on the order they are defined.:=can be replaced by=:=will be evaluated even if not needed. This will force evaluation of all called functions, in particular shell calls. This causes unnecessary overhead at minimum, or a failure that should not occur at most (think what happens if a tool is defined with:=but you don't have the tool and you don't need it either)I believe immediate assignments cause harder-to-debug problems because the order of definition starts to matter.
With respect to performance, if some variable is too expensive to evaluate more than once, there is a trick to memoize it (I think there is a PR by @cladmi ).
Finally, recursive variables fit better into the declarative style that good makefiles should follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a quote from the docs (:
Kidding aside, I am not very involved in the build system development and I don't know what the desired end result will look like. I was merely stating that I had problems with recursive evaluations in earlier projects and most of the time they lead to performance drops. If you think that recursive evaluations fit better in the picture, then I trust your judgement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reality is that we (and by that I mean @cladmi and me) should probably spend some time writing a proper guide to writing makefiles in RIOT.
That part of the docs is true, but it refers mainly to things like wildcards and shell calls with side-efects. Essentially, I/O. In our case
:=is most of the times workaround for this. The real solution is to more cleanly separate the functional and I/O parts of our makefiles.Performance drop in RIOT builds is mainly due to:
:=is involved here).This is probably more info than you asked for, but I feel this should be stated somewhere.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are doing recursive definitions you are not defining but doing evaluation.
Here I would say there is no need for evaluation so no
:=.usuallyI would say no, its only in RIOT that I saw this pattern.If you have
INCLUDESthat depends onINCLUDESyou should introduce a new name and doINCLUDES = $(INCLUDES_TOOLCHAIN) $(INCLUDES_C_LIBRARY)and defineINCLUDES_TOOLCHAINlater instead of prepending to the previous value.If you replace
pytermwith a function, it does nothing as you are not evaluating the name with$(pyterm).If a
shellcall is evaluated 100 times it can indeed slow down the build, but then only this one should be optimized. Also, with correct file targets you do not rebuild the target if not neheaderseded so do not re-evaluate the variable for nothing. It may make the clean build slower but makes incremental build faster.Also, by doing
:=everywhere you are makingmake cleanslow as it checks the warnings supported for yourgccversion even if you do not use it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cladmi @jcarrano This discussion was quite insightful for me, I think it would be great to have this documented somewhere, kind ok like the
advanced-build-system-tricks.mdbut abuild-system-basics.mdpage :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is somehow "gnumake" basics, but how it should be applied to
RIOTcould indeed be good.I never had any issues before as was not using recursive makefiles.
We still need to
exportthings and so how to counter the issues with it withmemoizedsomehow andtarget-export-variables.