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

Cross-compilation broken by custom Setup.hs used for doctests #82

Open
vmchale opened this issue Sep 14, 2020 · 16 comments
Open

Cross-compilation broken by custom Setup.hs used for doctests #82

vmchale opened this issue Sep 14, 2020 · 16 comments

Comments

@vmchale
Copy link

vmchale commented Sep 14, 2020

Currently, the custom Setup.hs used for doctests causes cross-compilation to fail due to a loingstanding cabal bug.

I set write-ghc-environment-files to always in my cabal.project and then just run doctest from the command-line as a workaround.

@georgefst
Copy link
Collaborator

Hmm, yeah, I would like to get away from using a custom setup if it's at all possible. There are a lot of issues around them, and this isn't the kind of library that justifies it. The pretty-simple tests quite often fail to run for me on GHC 8.10 anyway.

I'm sure there was talk at some point of a proper cabal doctest command? I'll have a look for that discussion.

@georgefst
Copy link
Collaborator

Running doctest from the project route is giving me cannot satisfy -package-id pretty-simple-3.3.0.0-inplace, even when I have an environment file which contains precisely that (generated by cabal repl --write-ghc-environment-files=always.

@vmchale How are you getting this to work?

@vmchale
Copy link
Author

vmchale commented Sep 14, 2020

I put them in my cabal.project file as a line like

write-ghc-environment-files: always

(perhaps you've run into another cabal bug 😬 )

@georgefst
Copy link
Collaborator

It doesn't seem to make a difference how I specify the flag (file vs. command line), which to be honest is a good thing...

I'm not very familiar with doctest though. To be clear, you're just running doctest, with no args, from the pretty-simple directory? If so then I guess I am hitting a bug.

FWIW, I'm using doctest 0.17 on pretty-simple's HEAD (763d769), with GHC 8.10.2, on Linux.

@vmchale
Copy link
Author

vmchale commented Sep 14, 2020

My workflow is

cabal build --write-ghc-environment-files always
doctest src

For whatever reason doctest by itself doesn't work. And I set build-type: Simple in the .cabal file

(I think cabal repl doesn't quite do what one wants; it doesn't build pretty-simple itself)

@georgefst
Copy link
Collaborator

(I think cabal repl doesn't quite do what one wants; it doesn't build pretty-simple itself)

Aha, you're right! I'd missed that subtlety.

@cdepillabout
Copy link
Owner

cdepillabout commented Sep 15, 2020

The problem with doctest is that it doesn't know how to find the required package database when running with the various Haskell build tools (stack, cabal-v1, cabal-v2, haskell environment from nixpkgs, haskell.nix).

cabal-doctest is the only reliable solution right now (although it still doesn't work with haskell.nix).

I don't want to move away from cabal-doctest until there is some other way to reliably run doctests.

However, as you've seen, the custom Setup.hs is only for the doctests, so as a workaround you should be able to delete the Setup.hs, change the build-type to Simple, and disable the doctests.

If you wanted to make this process a little easier, please feel free to send a PR putting the doctests under a flag that you can easily disable.

@georgefst
Copy link
Collaborator

Worth keeping an eye on: https://mail.haskell.org/pipermail/haskell-cafe/2020-August/132570.html

@dpwiz
Copy link

dpwiz commented Mar 16, 2021

BTW, lens did a similar update recently.

(An older version of lens and this package breaks with global -split-sections ghc flag.)

@georgefst
Copy link
Collaborator

Thanks @dpwiz, that link is very handy.

Looking at the cabal-docspec manual, I think that could be the perfect solution.

@georgefst
Copy link
Collaborator

If you wanted to make this process a little easier, please feel free to send a PR putting the doctests under a flag that you can easily disable.

Having just tried this, simply changing the one line to build-type: Simple is enough to get cross-compilation working. But it isn't something that can be put behind a flag AFAICT.

@cdepillabout
Copy link
Owner

There's a long thread on the Cabal issue tracker about doctests: haskell/cabal#4500

Recently sol commented about using cabal repl directly with doctest to run doctests: haskell/cabal#4500 (comment)

I'd be interested to see a comparison between cabal repl --with-ghc=doctest, cabal-docspec and cabal-doctests (including whether they easily work with stack, Nixpkgs haskell stuff, and haskell.nix).

@cdepillabout cdepillabout changed the title Cross-compilation broken by custom Setup.hs Cross-compilation broken by custom Setup.hs used for doctests Dec 25, 2021
@cdepillabout
Copy link
Owner

Looks like there is one more doctest contender in the mix, doctest-parallel:

One feature of doctest-parallel is that it apparently parses cabal files to discover modules, so you don't need a custom Setup.hs.

It would be great add a comparison to doctest-parallel to the list above

georgefst added a commit to georgefst/wreq that referenced this issue Apr 15, 2022
…rpreter`)

As it stands, we also need changes to `entropy`, but I'll manage that separately. Hopefully by reviving haskell#78.

Note that the custom setup is only used for `cabal-doctest`, so we really can just safely remove it. This is essentially the same issue as cdepillabout/pretty-simple#82.

Seeing as all the TH is just for `makeLenses`, in an ideal world we really ought to just be able to run on the host: see ghc-proposals/ghc-proposals#243.

The changes to the two `.hs` files are from dumping the TH splices (and manually (well, with _some_ help from HLS) adding a load of qualified imports). The splices can be found in `dist-newstyle` after adding this to `cabal.project`:

```
package wreq
    ghc-options: -ddump-splices -dth-dec-file
```
georgefst added a commit to georgefst/wreq that referenced this issue Apr 15, 2022
…rpreter`)

As it stands, we also need changes to `entropy`, but I'll manage that separately. Hopefully by reviving haskell/entropy#20.

Note that the custom setup is only used for `cabal-doctest`, so we really can just safely remove it. This is essentially the same issue as cdepillabout/pretty-simple#82.

Seeing as all the TH is just for `makeLenses`, in an ideal world we really ought to just be able to run on the host: see ghc-proposals/ghc-proposals#243.

The changes to the two `.hs` files are from dumping the TH splices (and manually (well, with _some_ help from HLS) adding a load of qualified imports). The splices can be found in `dist-newstyle` after adding this to `cabal.project`:

```
package wreq
    ghc-options: -ddump-splices -dth-dec-file
```
@cdepillabout
Copy link
Owner

cdepillabout commented Jul 15, 2022

There has apparently recently been a PR to cabal that adds a new doctest-related feature:

I haven't looked at this thoroughly, but this might be the best option so far, since it will officially be supported by cabal.

edit: This has been released in Cabal-3.8.1.0: https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/4920

@cdepillabout cdepillabout linked a pull request Nov 8, 2023 that will close this issue
@cdepillabout
Copy link
Owner

In #129 (comment), @andreabedini gave a link to haskell/cabal#9551, which may provide a better way to run doctests.

@georgefst
Copy link
Collaborator

In #129 (comment), @andreabedini gave a link to haskell/cabal#9551, which may provide a better way to run doctests.

Although it might be years before we're willing to drop support for all Cabal versions which don't support it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants