Conversation
|
looks good... ACK |
|
I like this, but would need some tricks to make it work correctly. It will not work now with boards where |
|
@cladmi I'll look into it |
|
Could be done by having a |
|
I do not have an Arduino-due available, but I think this should still work now. |
|
good catch, didn't check that. Un-ACK |
|
@smlng I have one, let me check |
|
I confirm it's working for Arduino Due. |
|
Not sure that it always works with parallel execution with "make flash -j 1000" on a clean environment as 'preflash' could be executed before building 'all'. |
|
But that should be a problem even with the current way the targets work, right, and hence is not a problem of this PR but rather a general one, even with current master. |
|
No, right now, preflash is done after 'all'. |
|
For the other things in |
|
mhm, I'm unsure what you mean. Currently the dependencies calling Where With this PR this only slightly changed, and |
The difference is that before, the flash recipe did the flashing, after its prerequisites were run (preflash and all). Now, flash has "all" and "flash-only" as prerequisites, they might be run at the same time, thus this breaks. Try |
|
Nah, another layer of recursion? try this (revert your fixup2 first): |
39869bd to
5158ed1
Compare
|
thanks @kaspar030, seems to work. |
Makefile.include
Outdated
| all $(BASELIBS) $(USEPKG:%=$(RIOTPKG)/%/Makefile.include) $(RIOTBUILD_CONFIG_HEADER_C) pkg-prepare: clean | ||
| endif | ||
|
|
||
| ifneq (,$(filter flash, $(MAKECMDGOALS))) |
There was a problem hiding this comment.
Wouldn't it make more sense to move this down to the flash targets?
I also don't understand how this works using a tab at the beginning. That should make it part of above's recipe, no?
There was a problem hiding this comment.
ah my bad, yes better to have it close to the flash targets
|
ACK from my side. @cladmi can you take another look? |
then you should hit Approve, too 😉 @cladmi, are we good here? |
|
Nope does not work as I expect it to. For me the
I don't have the board here to test so I just add 'echo' for So they must both The problem with your solution is that it modifies |
|
well, then we need to go for my previous code, which was like |
|
In the same idea as what you last proposed but inversed. And this has expected behavior even with
I used horrible variable naming convention to think a second time about it. |
/o\ why not use make instead of sneaking in shell scripts in? flash-only: $(FLASHDEPS)
[...]
flash: all flash-only |
|
Ah.... maybe I should have read @cladmi's previous comment ..... |
|
@cladmi thanks for testing, I adapted your proposed solution a bit, but this should work too. Can you check? |
|
Nop does not work. |
cae1ab1 to
28e3fc0
Compare
|
@cladmi try again, please 🤞 |
Makefile.include
Outdated
| -@rm -rf $(BINDIRBASE) | ||
|
|
||
| flash: all $(FLASHDEPS) | ||
| ifneq (,$(filter flash, $(MAKECMDGOALS))) |
There was a problem hiding this comment.
I prefer having a condition on flash-only here
As the check is on MAKECMDGOALS it means passed on the command line, so could break the current state if flash is set as a dependency of another target.
Also, the special case is required when flash-only is used, not when flash is used.
Makefile.include
Outdated
|
|
||
| flash: all $(FLASHDEPS) | ||
| ifneq (,$(filter flash, $(MAKECMDGOALS))) | ||
| PREFLASHDEPS += all |
There was a problem hiding this comment.
Its not really PREFLASHDEPS as its also a deps for flash.
I do not think it needs to be made generic with the += also.
What we actually mean here is "flash when the firmware is built", by saying firmware.elf/.bin as a dependency but we can't right now. Maybe more a FIRMWARE_IS_BUILT or something.
Could get some other inputs, I am bad at names.
Makefile.include
Outdated
| preflash: all | ||
| flash-only: flash | ||
|
|
||
| preflash: $(PREFLASHDEPS) |
There was a problem hiding this comment.
The flash: and preflash: works now the same as before.
|
To summarize, yes the current patch works as expected. There are things I would prefer to be written differently but its my personal point of view and if other maintainers like it, it can go like this. |
28e3fc0 to
0374bbc
Compare
|
@cladmi I changed the logic/condition to work on the new |
|
Looks good. I will test again but you can already squash and rebase. |
|
Sorry, please also add a comment for the |
|
Tested with |
|
Please squash and rebase. |
2328fe2 to
c4194d4
Compare
|
@kaspar030 addressed your comments. |
When flash-only was introduced (in RIOT-OS#8373), the `flash` rule was made conditionally dependent on `all` by looking for `flash-only` in MAKECMDGOALS. This was done to avoid code duplication. There's a cleaner way, by using canned recipes.
When flash-only was introduced (in RIOT-OS#8373), the `flash` rule was made conditionally dependent on `all` by looking for `flash-only` in MAKECMDGOALS. This was done to avoid code duplication. There's a cleaner way, by using canned recipes.
When flash-only was introduced (in RIOT-OS#8373), the `flash` rule was made conditionally dependent on `all` by looking for `flash-only` in MAKECMDGOALS. This was done to avoid code duplication. There's a cleaner way, by using canned recipes. When we upgrade the requirements to gnu make 4, the flash recipe can be defined as ?=.
When flash-only was introduced (in RIOT-OS#8373), the `flash` rule was made conditionally dependent on `all` by looking for `flash-only` in MAKECMDGOALS. This was done to avoid code duplication. There's a cleaner way, by using canned recipes. When we upgrade the requirements to gnu make 4, the flash recipe can be defined as ?=.
When flash-only was introduced (in RIOT-OS#8373), the `flash` rule was made conditionally dependent on `all` by looking for `flash-only` in MAKECMDGOALS. This was done to avoid code duplication. There's a cleaner way, by using canned recipes. When we upgrade the requirements to gnu make 4, the flash recipe can be defined as ?=.
Contribution description
PR adds new make target named
flash-onlywhich does not depend on targetall. In some cases make rebuilds the binary before flashing even though nothing changed or the last build is only seconds old. Theflashtarget still behaves the same and relies onall.Issues/PRs references
None