Don't put attoparsec in its own library

[st3ll1s]

This reverts 3bf3d4c as a temporary fix for two problems:

1. Rebuilds with stack: hakyll dependency on nightly is not cached commercialhaskell/stack#3899, stack test rebuilds haddock-library-1.5.0.1 jgm/pandoc#4482
2. Can't document itself? cabal haddock fails with internal libraries cabal#4969

The stack issue doesn't seem to have a clear solution and easy haddocks for haddock should make contributions easier. The revert seems like the simplest solution to me.

[alexbiehl]

Hmm, maybe it would be easier to just rename the internal sublib to something like haddock-attoparsec or something. That might be even easier considering the obscure cpp errors travis runs into.

[alexbiehl]

Also do we have any indication as to why stack rebuilds this stuff all the time? I imagine sublibs will pop up more and more in the future.

[st3ll1s]

I think the errors are caused by missing dependencies, CPP just gives bad error messages. I added the dependencies, hopefully this works now. I've tested renaming (commercialhaskell/stack#3899 (comment)), it didn't work for me.

[gbaz]

This issue occurs with stack with all packages with internal libraries, it seems, regardless of name.

[mimi1vx]

@gbaz

$/usr/bin/ghc-pkg-8.2.2 -f /home/mimi/ghcmacros/package.conf.d/ -v0 --simple-output --global field haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec name
haddock-library
$ /usr/bin/ghc-pkg-8.2.2 -f /home/mimi/ghcmacros/package.conf.d/ -v0 --simple-output --global field haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec id
haddock-library-1.4.5-uQdrVGi1uKLD22IlKGc6n
$/usr/bin/ghc-pkg-8.2.2 -f /home/mimi/ghcmacros/package.conf.d/ -v0 --simple-output --global field haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec depends
base-4.10.1.0 bytestring-0.10.8.2 transformers-0.5.2.0 haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec

so we don't have provided haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec but haddock-library depends on it

[gbaz]

@mimi1vx I don't understand. Who is "we"? What problem are you describing? Is this a build failure? Using what tooling? The commands don't quite make sense to me -- why is there a package.conf.d in that folder, and why are you using both -f and --global? Don't they overlap? I this a quirk in ghc-pkg output or are there symptoms? Is this an issue with internal libraries in general?

[mimi1vx]

@gbaz '-f' and '--global' don't overlap, it simply uses system package.conf.d + another in specified directory

problem is: library has specified dependency on an internal library, but ghc-pkg or any other tool didn't get what provides that dependency so never be correctly resolved

[gbaz]

resolved by who? in what context? this sounds like a general issue with internal libraries that should be taken up with the ghc team?

[gbaz]

In particular, it looks like you're querying the db for haddock-library-1.4.5-JMywL3gQR7h8vuSGU4Yu5w-attoparsec, and in fact finding it. You just notice that its name and id are the same as that of haddock-library -- which I suspect is intentional. But I'm not an expert on the mechanics of these things.

[mihaimaruseac]

With commercialhaskell/stack#3955 merged, there is no longer a case where the internal library gets confused and rebuilt

[alexbiehl]

With 79c7159 we got rid of attoparsec alltogether.