Makefiles: Remove duplicate object files when linking.

[pfalcon]

Scenario: module1 depends on some common file from lib/, so specifies it
in its SRC_MOD, and the same situation with module2, then common file
from lib/ eventually ends up listed twice in $(OBJ), which leads to link
errors.

Make is equipped to deal with such situation easily, quoting the manual:
"The value of $^ omits duplicate prerequisites, while $+ retains them and
preserves their order." So, just use $^ consistently in all link targets.

[pfalcon]

@dpgeorge , @dhylands, @galenhz : See #1517 (comment) for real-world usecase.

[dhylands]

I don't have any particular issue with the solution, but it begs the question of why there are duplicates in OBJ in the first place.

I think that the fundamental problem is that module 1 is not only saying that it depends on some common lib, but that it's providing the objects. Then module 2 is coming along and doing the same thing.

Module1 shouldn't be trying to provide the files from lib. It should have a dependency on lib. The lib should be the only place that adds the object files.

[pfalcon]

See commit message and comments linked.

[dpgeorge]

I'm ok with these changes. Simple enough (and arguably should have been done this way from the start, using a built-in $ variable instead of $(OBJ)).

Module1 shouldn't be trying to provide the files from lib. It should have a dependency on lib. The lib should be the only place that adds the object files.

Right, but changing to such a scheme would require a lot of restructuring of the Makefile's no? And I'm not exactly sure how it would work...

[pfalcon]

Module1 shouldn't be trying to provide the files from lib. It should have a dependency on lib. The lib should be the only place that adds the object files.

As I mentioned in discussion by the link above, I though myself that proper resolution of this issue would require building stuff in lib/* as proper lib*.a files and linking against them. Fortunately, this automagic solution with $^ exists. And I'd be actually -1 on adding (more) static libs to build process (more because there's already libaxtls.a and libffi.a are being built - optionally so far). The reason is that we have 2 conflicting requirements: 1) elaborate our own build system, and 2) allow easy integration with 3rd-party build systems. Well, 2nd one never was a requirement, but a case that micro:bit port isn't even a git fork of mainline should give good hint that something needs to be done about that. (More info: http://forum.micropython.org/viewtopic.php?f=8&t=1042&start=10). So, again, keeping our build system simple (e.g. working on single, as large as possible set of source files) is at least not going the opposite direction.

[pfalcon]

Merged.