Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine command line options to doctest based on .cabal file #6

Closed
sol opened this issue Jul 24, 2011 · 10 comments
Closed

Determine command line options to doctest based on .cabal file #6

sol opened this issue Jul 24, 2011 · 10 comments
Milestone

Comments

@sol
Copy link
Owner

sol commented Jul 24, 2011

Say doctest foo.cabal should run all doctests for project foo and take care of the details.

@ekmett
Copy link
Contributor

ekmett commented Dec 16, 2012

Something like ekmett/lens@d2459a0 can help with the actual package versions. You could augment the Build_doctests file I build with more information from the ghc-options of the build.

@aavogt
Copy link
Collaborator

aavogt commented Oct 2, 2013

An approach that doesn't need a build-type: Custom like ekmett's solution is to get the flags by interacting with the ghci started with cabal repl. This is done in here http://code.haskell.org/~aavogt/HList/examples/rundoctests.hs.

@ekmett
Copy link
Contributor

ekmett commented Oct 2, 2013

That ties you rather inextricably to the current version of Cabal though.

@sol
Copy link
Owner Author

sol commented Oct 2, 2013

Yes, same thought here, looks pretty cool, but only works with cabal-install 1.18.* + the cabal executable has to be on your path.

@trofi
Copy link

trofi commented Feb 3, 2014

@aavogt you approach does not work for cases when package collisions
occur (i came here actually when have seen doctest failure in latest HList):

Data/HList/Labelable.hs:44:8:
    Ambiguous module name `Control.Monad.Identity':
      it was found in multiple packages:
      mtl-2.1.2 monads-tf-0.1.0.1 monads-fd-0.2.0.0

This bug is very interesting:
Cabal builds exactly the same commandline for ghc --make: --hide-all-packages -package=foo -package=bar etc.
which doctest needs for ghci ${the-same}.

Would be great if @dcoutts or @23Skidoo gave an advice on how to rebuild cmd here.

@23Skidoo
Copy link

23Skidoo commented Feb 3, 2014

@trofi Doesn't cabal repl already imply --hide-all-packages?

@aavogt
Copy link
Collaborator

aavogt commented Feb 3, 2014

@trofi the doctest test failure, provided it's the one below, would be fixed if we had #63 in a release

### Failure in ./Data/HList/TIP.hs:163: expression `Sheep .*. myTipyCow'
expected: -- type error --

I will take a look at adding --hide-all-packages to that script

@trofi
Copy link

trofi commented Feb 3, 2014

@aavogt oh, looks like cabal-install -HEAD handles it better, than current release.

@23Skidoo it does (looks like in -HEAD only), but AFAIU ideally doctest needs one level deeper:

doctest testsuite needs to know depends it was built against to rerun ghci
with the same options (see lens and hlist doctest tests).

Is there an easy way in cabal to dump all args like this thing in lens
tries to gather manually? ekmett/lens@d2459a0

Would be fun to have something like Paths_$package.hs but for CompilerOptions_$package.hs.

Thanks!

@23Skidoo
Copy link

23Skidoo commented Feb 3, 2014

@trofi I don't understand - if you're using cabal repl, why do you need to extract compiler options?

@sol
Copy link
Owner Author

sol commented Nov 15, 2021

doctest-0.20.0 can now be run via cabal repl --with-ghc=doctest. I think this appropriately addresses this issue.

@sol sol closed this as completed Nov 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants