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

Duplicate entries in connection with Alex and Happy #406

Closed
andreasabel opened this issue Nov 9, 2020 · 2 comments · Fixed by #408
Closed

Duplicate entries in connection with Alex and Happy #406

andreasabel opened this issue Nov 9, 2020 · 2 comments · Fixed by #408

Comments

@andreasabel
Copy link
Contributor

This might be the same problem as #353 .
From these files in the source directory:

LBNF
├── Abs.hs
├── ErrM.hs
├── Lex.hs
├── Lex.x
├── Par.hs
├── Par.y
├── Print.hs
├── Skel.hs
└── Test.hs

I am getting this entry in the generate .cabal file:

library
  exposed-modules:
      LBNF.Abs
      LBNF.ErrM
      LBNF.Lex
      LBNF.Lex
      LBNF.Par
      LBNF.Par
      LBNF.Print
      LBNF.Skel
      LBNF.Test

Cabal does not like this:

$ hpack && cabal build
generated Foo.cabal
Resolving dependencies...
Error:
    Module name  LBNF.Lex  is exported multiple times.
    In the stanza 'library'
    In the inplace package 'Foo...'

Manually deleting the duplicate entries helps.

Suggestion: nub the generated list.

andreasabel added a commit to andreasabel/hpack that referenced this issue Nov 10, 2020
Inserting a `nub` here is strictly improving the state of affairs,
since cabal chokes on a module list with duplicates.

This patch might also fix sol#353.
@sol
Copy link
Owner

sol commented Nov 10, 2020

@andreasabel hey! Thanks for bringing this up!

Not opposed to your suggestion of remove duplicates. But I would still want to have the full picture first.

How did Lex.hs/Par.hs end up in your source tree? I would assume that Cabal generates them in dist/build/autogen (or some new-style equivalent).

@sol sol closed this as completed in #408 Nov 10, 2020
sol pushed a commit that referenced this issue Nov 10, 2020
Inserting a `nub` here is strictly improving the state of affairs,
since cabal chokes on a module list with duplicates.

This patch might also fix #353.
@andreasabel
Copy link
Contributor Author

Thanks for the quick fix.

@andreasabel hey! Thanks for bringing this up!

Not opposed to your suggestion of remove duplicates. But I would still want to have the full picture first.

How did Lex.hs/Par.hs end up in your source tree? I would assume that Cabal generates them in dist/build/autogen (or some new-style equivalent).

These files have been sitting in the source tree since I originally did not use any cabal configuration for this project (just a Makefile). To generate a cabal file, I used hpack and then ran into the problem of duplicates.

I think in case of Alex and Happy, my problem can be circumvented by not checking in the generated hs files into the source tree. However, Alex and Happy are natively supported by Cabal. Other build tools (such as my own, BNFC) do not enjoy the support by Cabal. Therefore, I also check in the files generated by the build tool into the source tree.

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.

2 participants