Daniel Gröber (dxld)

I'm happy enough to do some convincing :) So the entire reason for this is that I finally want to get rid of the separate compilation step for libopencm3 itself...

Ah, I'm an idiot. Doing most of the work in the target makefiles makes this a lot easier. I managed to get rid of all the duplication and evil .....

If you point me to the Makefile bits that bother you most I'm happy to add some comments. I hate make as much as the next guy but after spending...

There you are, please see the commit message for more commentary. I've tested the new LIBNAME mechanism agains each and every entry in devices.data so that should all be good....

Changes: - Rebased on master 72274d3caf09a5b4a6646e65bf376c91b8fa2ef1 seems to have incoorporated most but not all of my `Makefile: Use relative paths to refer to dirs above target` commit but git was...

Seems the part of this that wasn't pulled out to #1301 got superseded by d60d7802fd20821a766675545b6ef7a2207207a3.

Is changing the backend C library not likely to change misaka's behaviour in subtle ways and just potentially introduce new bugs? i.e. is this really a good idea? Let me...

I don't want to maintain hoedown by myself either really :), but just looking at how many other libraries are using it I have a feeling efforts could be pooled...

> `--enable-dumpbuildinfo` So is the idea for this new flag that this is what controls the generation of buldinfo.json by `Setup.hs build` and `--dump-buildinfo=` writes the list of paths for...

I should probably also mention that this will also make life easier for Haskell-IDE-Engine because we also have to (eventually) parse cabal build output for diagnostics there.