Currently we're letting exactprint perform CPP expansion. It does this by reading a settings file at runtime from a hardcoded location deep inside your machine's GHC installation, then shelling out to CPP. If the file isn't there, it throws an exception. This isn't great, because it makes it hard to publish portable binaries from Travis etc.
We have a couple of alternatives:
Stop expanding CPP (reduces the utility of the tool significantly and makes #19 impossible)
Live with it, stop trying to distribute binaries
Use a pure-Haskell CPP implementation, like cpphs
I lean towards cpphs, which we can later populate on the fly with cabal macros.
It would be worthwhile first confirming that exactprint is properly portable once CPP is disabled!
This is something I'd rather do once we have benchmarks in place, because something like cpphs may come with a significant cost. It'd be bearable given we're pretty slow already, but would like to see the impact before switching over.
Currently we're letting exactprint perform CPP expansion. It does this by reading a settings file at runtime from a hardcoded location deep inside your machine's GHC installation, then shelling out to CPP. If the file isn't there, it throws an exception. This isn't great, because it makes it hard to publish portable binaries from Travis etc.
We have a couple of alternatives:
cpphsI lean towards
cpphs, which we can later populate on the fly with cabal macros.It would be worthwhile first confirming that exactprint is properly portable once CPP is disabled!
This is something I'd rather do once we have benchmarks in place, because something like
cpphsmay come with a significant cost. It'd be bearable given we're pretty slow already, but would like to see the impact before switching over.