Skip to content

Move sources into src/ #391

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

Closed
phadej opened this issue May 22, 2021 · 4 comments
Closed

Move sources into src/ #391

phadej opened this issue May 22, 2021 · 4 comments

Comments

@phadej
Copy link
Contributor

phadej commented May 22, 2021

... away from top-dir.

This is in general good practice, and also helps with testing (e.g. one can use .ghc.environment.* file to compile local throw-away examples against compiled library)

@sjakobi
Copy link
Member

sjakobi commented May 23, 2021

helps with testing (e.g. one can use .ghc.environment.* file to compile local throw-away examples against compiled library)

Sounds like a neat trick! Is it documented anywhere or could you briefly explain it?

@phadej
Copy link
Contributor Author

phadej commented May 23, 2021

When you do cabal build and have write-ghc-environment-files: always enabled, cabal writes the .ghc.environment.<ghc-version-id> file. That file is then used by ghc (if no -package-env= supplied). Read about environment files in GHC manual.

It e.g. makes raw doctest work (which haskell-ci uses), or ghc my-example.hs. However, especially for later, you have to make sure that ghc doesn't find any other sources. Now as I say that, maybe -i would work too (-i without argument clears search path, including default current directory .)

@Bodigrim
Copy link
Contributor

Dunno, current folder structure allows running throw-away examples without much hassle: I just drop examples in the root folder and run ghc Foo.hs, which compiles necessary bytestring modules on demand.

I do not have a strong opinion and do not particularly mind to change. But let's not get in a way of existing long-standing PRs such as #365 and wait until they are merged.

@phadej
Copy link
Contributor Author

phadej commented May 27, 2021

My point is exactly to not let GHC rebuild the (parts of) bytestring (with default settings, not using Cabal configuration, e,.g. developer flag).

This issue arised because debugging #393 was trickier that I felt it needs to be.

As there is no unanimous agreement, I'll just close this.

@phadej phadej closed this as completed May 27, 2021
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

No branches or pull requests

3 participants