cabal-install package includes useful modules. With these modules it is possible to read the actual build info. These modules could be added to the Cabal API. What are the reasons cabal-install can not be added as a project dependency? Can some modules be moved from cabal-install to Cabal library? On 25 July 2018 at 11:33, Félix Baylac wrote:

Dear cafe,

I am currently working on a project [1] which aims to index the code published on Stackage in order to provide a "code example" database. Basically, for each library, I want to generate a real-world example corpus for each exported symbol.

Before generating this database, I need to retrieve the exported symbol of a package. So far, I have been gathering the dependencies and integrating them in the GHC pkg database using an external stack call, I then parse the cabal file and load the exposed modules using the GHC API and gather the exported symbols*.

It works pretty reliably on the simple packages, however, I end up with some missing dynamic flags for some more advanced packages (missing c includes, c libraries, ASM flags, etc.). I then started to parse and load these missing attributes to GHC until I stepped back for a moment and realized I was re-implementing cabal build.

I then looked for a way to "hook" my GHC API code in cabal build. This would allow cabal to both handle the dependencies gathering as well as setting up the correct GHC dyn-flags. The only resource I found was [2]. It's really clever, however, looks a bit hacky to me.

Is there a better way to perform this kind of "hook"?

[1] https://git.alternativebit.fr/NinjaTrappeur/Exhs [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api- programs-with-cabal/

* I am aware of the hoogle index generated by haddock. However, this index is missing when the haddock documentation of a package cannot be generated. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

You can implement your tool as a source plugin and then it will work with any method of building. On Wed, 25 Jul 2018, 10:34 Félix Baylac, wrote:

Dear cafe,

I am currently working on a project [1] which aims to index the code published on Stackage in order to provide a "code example" database. Basically, for each library, I want to generate a real-world example corpus for each exported symbol.

Before generating this database, I need to retrieve the exported symbol of a package. So far, I have been gathering the dependencies and integrating them in the GHC pkg database using an external stack call, I then parse the cabal file and load the exposed modules using the GHC API and gather the exported symbols*.

It works pretty reliably on the simple packages, however, I end up with some missing dynamic flags for some more advanced packages (missing c includes, c libraries, ASM flags, etc.). I then started to parse and load these missing attributes to GHC until I stepped back for a moment and realized I was re-implementing cabal build.

I then looked for a way to "hook" my GHC API code in cabal build. This would allow cabal to both handle the dependencies gathering as well as setting up the correct GHC dyn-flags. The only resource I found was [2]. It's really clever, however, looks a bit hacky to me.

Is there a better way to perform this kind of "hook"?

[1] https://git.alternativebit.fr/NinjaTrappeur/Exhs [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with-cabal/

* I am aware of the hoogle index generated by haddock. However, this index is missing when the haddock documentation of a package cannot be generated. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.