Skip to content
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

--parallel improvements #13800

Merged
merged 3 commits into from
Aug 17, 2021
Merged

--parallel improvements #13800

merged 3 commits into from
Aug 17, 2021

Conversation

RuRo
Copy link

@RuRo RuRo commented Jul 30, 2021

Description

This PR has 2 improvements for --parallel support with make

  1. parallel values less than 1 will now mean "unlimited" (see make --help | grep -- --jobs). This is not a breaking change, because currently non-positive parallel values fail with make: the '-j' option requires a positive integer argument.

  2. If more than 1 job is used, the --output-sync option is also added. The stdout/stderr of each job will be collected by make and displayed synchronously, after each target is finished processing. This will fix [Feature Request] Prettier make output with parallel build #13707.

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
    (Not sure, if this is a "Core PR", so submiting it against master for now)
  • My change requires a change to the documentation.
    (Not sure if qmk --help counts as documentation and I didn't find any references to --parallel in the online docs)
  • I have updated the documentation accordingly.
    (I updated the qmk --help for subcommands that have --parallel)
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

@github-actions github-actions bot added cli qmk cli command python labels Jul 30, 2021
@zvecr zvecr requested review from skullydazed, Erovia and a team July 30, 2021 23:47
@drashna
Copy link
Member

drashna commented Jul 31, 2021

this should probably target develop

@drashna drashna requested a review from a team July 31, 2021 00:40
@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

this should probably target develop

Sure, I can open a new PR, that targets develop, if you want. I originally targeted master, because I assumed that "Core" mostly meant the stuff that's written in C like tmk_core.

@tzarc tzarc changed the base branch from master to develop July 31, 2021 00:46
@tzarc
Copy link
Member

tzarc commented Jul 31, 2021

Sure, I can open a new PR, that targets develop

No need, this is sorted already.

@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

Oh, I didn't know, that GitHub allows changing the target branch after the fact. Neat. Do you want me to force-push the changes with the resolved conflict for develop?

@drashna
Copy link
Member

drashna commented Jul 31, 2021

Oh, I didn't know, that GitHub allows changing the target branch after the fact. Neat. Do you want me to force-push the changes with the resolved conflict for develop?

Yes, please. And that conflict is part of my concern, since I know that a lot of CLI stuff got changed.

Copy link
Member

@skullydazed skullydazed left a comment

Choose a reason for hiding this comment

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

Good change! Besides my recommendations this will need a documentation update before merge.

lib/python/qmk/cli/compile.py Outdated Show resolved Hide resolved
lib/python/qmk/cli/flash.py Outdated Show resolved Hide resolved
lib/python/qmk/cli/multibuild.py Show resolved Hide resolved
lib/python/qmk/commands.py Show resolved Hide resolved
lib/python/qmk/commands.py Outdated Show resolved Hide resolved
lib/python/qmk/commands.py Show resolved Hide resolved
@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

AFAIK, the --parallel flags aren't documented anywhere in the docs, so I am not sure, where should it be documented if not in the --help.

@skullydazed
Copy link
Member

AFAIK, the --parallel flags aren't documented anywhere in the docs, so I am not sure, where should it be documented if not in the --help.

If it's not in docs/cli_commands.md that's an oversight. Seems like a good time to fix that. :)

@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

If it's not in docs/cli_commands.md that's an oversight. Seems like a good time to fix that. :)

Okay, I'll add it to docs/cli_commands.md, but I still think that the special -j 0 variant should be mentioned in --help.
Do you have any reasons for removing it?

@skullydazed
Copy link
Member

Honestly, I think it may be more about the parens than anything else. If the information needs to be there it should be worked in naturally. The example from make itself is an ok (but not good) example of what I'm looking for:

  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.

That particular wording assumes more knowledge than I wish it did.

@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

Honestly, I think it may be more about the parens than anything else. If the information needs to be there it should be worked in naturally.

There are 2 hard problems in computer science... apparently, writing helpful help messages is one of them 😆.

I really can't come up with anything better. The problem stems from the fact that make has pretty weird --jobs semantics itself, so qmk compile does too. How about just changing the parentheses to a semicolon like in make:
Set the number of parallel make jobs; 0 means unlimited.?

Also, I've added some documentation to docs/cli_commands.md.

@zvecr
Copy link
Member

zvecr commented Jul 31, 2021

--output-sync currently messes with the :flash code (which is used by qmk flash). You can end up with zero output sometimes, looking like it's hanging:

Checking file size of ergosaurus_default.hex                                                        [OK]
 * The firmware size is fine - 23192/28672 (80%, 5480 bytes free)






^CWaiting for USB serial port - reset your controller now (Ctrl+C to cancel)..............make[1]: *** [tmk_core/avr.mk:338: flash] Interrupt
make: *** [Makefile:529: ergosaurus:default:flash] Interrupt

I dont get the "port - reset your controller now" till i ctrl+c.

With that, it might be only qmk compile that can have the proposed change.

@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

@zvecr Unfortunately, I am currently unable to test the flash step as I temporarily don't have my keyboard. Can you double check, that qmk flash -j N (N>1) works for you with the current develop branch?

--output-sync just buffers the text output to the terminal, so in theory it shouldn't affect the actual result. Keep in mind, that with --output-sync the output/progress of each build target is only printed after the target is completed, so it might look like it's stuck. From the output, it seems that you killed the flash process early.

Edit: nvm, I understand that the problem is just that the prompt doesn't appear, since it's buffered. I'll take a look at what can be done to fix this. Probably tomorrow tho.

@github-actions github-actions bot added the core label Jul 31, 2021
@RuRo
Copy link
Author

RuRo commented Jul 31, 2021

Okay, I think, I've found a solution. @zvecr can you please test qmk flash with the latest changes?

It's not that pretty of a solution, but it should work. Basically, --output-sync=target only buffers the outputs from "normal" commands. Recursive make commands are only buffered with --output-sync=recurse.

A leading + plus sign tells make to treat the following line as if there is a $(MAKE) variable present, which temporarily disables the buffering. After that, we just need to add $(UNSYNC_OUTPUT_CMD) to every command, that requires user interaction and should not be buffered (like the various flash targets).

For now, I added it to arm_atsam.mk, avr.mk and chibios.mk in:

  • EXEC_TEENSY
  • EXEC_DFU/EXEC_DFU_UTIL
  • EXEC_AVRDUDE
  • EXEC_USBASP
  • EXEC_BOOTLOADHID
  • EXEC_HID_LUFA
  • custom PROGRAM_CMD for the flash targets

Not sure, if I missed anything.

@RuRo
Copy link
Author

RuRo commented Aug 7, 2021

Btw, I checked qmk flashing in parallel with my moonlander and the prompt now appears as expected.

@RuRo RuRo requested a review from skullydazed August 11, 2021 21:53
@RuRo
Copy link
Author

RuRo commented Aug 11, 2021

@zvecr can you please verify, that your issue was resolved with the latest changes?

Copy link
Member

@drashna drashna left a comment

Choose a reason for hiding this comment

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

Have tested with stm32-dfu, atmel-dfu, and teensy halfkay bootloader, and all work as expected.

@RuRo
Copy link
Author

RuRo commented Aug 17, 2021

I've resolved the conflicts with recent refactoring changes, that moved parts of tmk_core/*.mk to platforms/*/flash.mk.

Also, I'm marking the changes requested by @skullydazed as resolved for now. I've added the required documentation and the long options. The remaining requested changes don't seem to apply any more. Feel free to reopen them if I've missed anything.

@tzarc tzarc merged commit 3b28178 into qmk:develop Aug 17, 2021
@drashna
Copy link
Member

drashna commented Aug 25, 2021

Hmm, this breaks the :bootloader target (for avr).

Specifically, outputs:

Making handwired/tractyl_manuform/5x6_right with keymap drashna and target bootloader

make[2]: Nothing to be done for `clean'.
touch obj/BootloaderDFU.o
touch obj/Descriptors.o
touch BootloaderDFU.elf
touch BootloaderDFU.hex
touch BootloaderDFU.eep
touch BootloaderDFU.bin
touch BootloaderDFU.lss
touch BootloaderDFU.sym
BootloaderDFU.hex copied to handwired_tractyl_manuform_5x6_right_drashna_bootloader.hex

Rather than actually generating the bootloader. Using the make command version works just fine, though.

@RuRo
Copy link
Author

RuRo commented Aug 25, 2021

@drashna

I am not sure, if I understand, what is the issue here. Can you provide more info?

What command did you run? What did you expect to happen? What happened instead? Is it still working as expected, if you run it without --parallel jobs? Was it working as expected before this PR was merged? Is the lufa submodule clean and unmodified?

Are you running qmk flash -kb handwired/tractyl_manuform/5x6_right -km drashna -bl bootloader? Are you sure, that this is a correct usage? Running this command with -b lists the following valid options for the bootloader:

Ψ Here are the available bootloaders:
	dfu
	dfu-ee
	dfu-split-left
	dfu-split-right
	avrdude
	BootloadHID
	dfu-util
	dfu-util-split-left
	dfu-util-split-right
	st-link-cli
	st-flash
For more info, visit https://docs.qmk.fm/#/flashing

Running make manually prints Please set BOOTLOADER to "qmk-dfu" or "qmk-hid" first!. Stop. for me. Did you modify the rules.mk?

After manually setting the BOOTLOADER option to qmk-dfu in rules.mk, the qmk flash ... -bl bootloader command seems to produce almost the same output as make ...:bootloader.

@RuRo
Copy link
Author

RuRo commented Aug 31, 2021

It's that time of the week, where I go around all the PRs I am participating in and ping everyone!

@drashna am I correct in assuming, that you've resolved your issue?

nhongooi pushed a commit to nhongooi/qmk_firmware that referenced this pull request Dec 5, 2021
* improve make parallel jobs support

* document the --parallel option

* disable the output-sync for interactive targets
BorisTestov pushed a commit to BorisTestov/qmk_firmware that referenced this pull request May 23, 2024
* improve make parallel jobs support

* document the --parallel option

* disable the output-sync for interactive targets
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Prettier make output with parallel build
5 participants