Cabal should define HASKELL_DIST_DIR

[nomeata]

Test suites often want to run executable from dist/. Now dist/ is not always dist/, so an environment variable to indicate the position of dist would be nice.

stack sets HASKELL_DIST_DIR to this value. It would be nice if this were done by Cabal, so that other modes of building Haskell packages benefit from this convenience.

[dcoutts]

And/or adjusting the $PATH so that the other exes are just directly available.

[23Skidoo]

Good idea.

[dcoutts]

Actually given that the layout of the dist dir is not fixed (and we really should rationalise it at some point), it'd be better for the longer term to put the exes on the $PATH. But compatibility with whatever stack picked is also useful.

[Blaisorblade]

Actually given that the layout of the dist dir is not fixed (and we really should rationalise it at some point), it'd be better for the longer term to put the exes on the $PATH.

Note that's not the only usecase, there's also doctests grabbing the generated files:
sol/doctest#127

And I'd guess people will find more uses for this.

I think the doctests's thing is somewhat hacky, whence the custom Setup.hs used by ekmett and copy-pasted around Hackage, but this is what we have today.
ekmett/distributive#17 (comment)

[ezyang]

If you apply this patch set #3662 then all internal build-tools will be put in your PATH. Not exactly what is asked for here, but should solve certain use-cases.

[ezyang]

Given that Stack sets the env var before calling Setup, I guess cabal-install should be the one responsible for setting it here?

[Blaisorblade]

Given that Stack sets the env var before calling Setup, I guess cabal-install should be the one responsible for setting it here?

I think yes.

If you apply this patch set #3662 then all internal build-tools will be put in your PATH. Not exactly what is asked for here, but should solve certain use-cases.

Thanks. But test suites aren't build tools (and build tools aren't in dist), are they? Maybe they can be added too?

[ezyang]

Thanks. But test suites aren't build tools (and build tools aren't in dist), are they? Maybe they can be added too?

You won't be able to put a test-suite in build-tools. But I thought the use-case here was calling an executable from a test suite; executables can be put in build-tools

executable bar
   ...
test-suite foo
  build-tools: bar

[Blaisorblade]

@ezyang Ah! I see — it looks like the original use case from @nomeata could work with your suggestion (looking at nomeata/arbtt@a114ff9 which seems the concrete example of the OP). So that's probably good.

But let me remind:

But compatibility with whatever stack picked is also useful.

Also, this isn't enough for other uses.

Ones I'm familiar with, but that might warrant better fixes:

• doctests (as above), or more in general finding generated headers
• hacking build introspection for now without the current Setup files. Which could be good for doctests actually — the doctests problem is that it's a library linked in the program, hence it can't easily talk to the Cabal version used by the build process.

TL;DR.: it seems Haskell libraries needing hooks into Setup.hs don't compose just so.

Unless maybe those hooks are rephrased using https://hackage.haskell.org/package/cabal-helper? (Related to #3065 and #2395).
But I suspect cabal-helper should still use HASKELL_DIST_DIR.

[ezyang]

I don't know what should be done about doctest. Would have to sit down and think about it. Anyway go look at the PR for this bug.