One additonal thing: This most likely breaks code downstream, which expects the micropython binary (or mpy-cross binary, or libmicropython.a) to show up in the working directory rather than the build directory.

Added a commit which might fixes the appveyor run .. if not I need help debugging this (where's appveyor.yml?)

One additonal thing: This most likely breaks code downstream, which expects the micropython binary (or mpy-cross binary, or libmicropython.a) to show up in the working directory rather than the build directory.

Yes this will break my (and probably other's) daily workflow, where I have grown accustomed to the unix (and mpy-cross) executables to be where there currently are.

Although I do agree it's neater (and follows the bare-metal ports output) to put these excutables in the build/ directory... just need to think how big of a breaking change this is.

It also breaks my workflow, but not in a way that I really feel very strongly about and can easy adapt (or symlink around).

Overall I'm in favour of merging this.

Hmm ... I could add a rule which moves the build output to where it was, an option to turn that rule off, and make the rule enabled by default?
That way someone running into problems with the current setup (for example someone with a readonly source directory) can just use that option?

And one could (step by step) first deprecate the current behaviour, and then some time in the future (when everybody had time to adjust) remove it?

edit, clarification:

• add a rule which move build output so that after merging this branch, everything still looks the same from the outside.
• allow this rule to be deactivated. By default the rule however is activated.
• Add a warning that the future behaviour will change.
• In future, by default deactivate the rule (but leave the option to activate it)
• Perhaps, in far future, remove the rule.

I nearly suggested exactly this, but you'd still want to make the other changes to reference the mpy-cross and micropython binaries from the build directories, so I think having two copies of the binary is just a recipe for confusion.

I think if we are going to merge this PR, then just do it without the backwards compatible copy/link.

Would it make sense to remove the PROG ?= micropython-coverage etc lines from mpconfigvariant.mk files, now that these executables live in build directories with the variant name, eg build-coverage/micropython?

Yes, +1 to that.

Merged in b2e8240 through c7aa6a2, and -coverage etc suffix removed in d53c3b6

I also reverted some of the changes to the mpy-cross dependency. It should be that if you define MICROPY_MPYCROSS_DEPENDENCY then that disables the automatic building of mpy-cross.

Thank you @musteresel for this contribution, it does clean up things nicely!