[Haskell-cafe] Integrate GHC-API with Cabal

[Félix Baylac]

Hi,

Thanks for the reply, I somehow missed your message.

> 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.

As mentionned in another reply, there's even a library[1] retrieving this kind of
informations.
 
> What are the reasons cabal-install can not be added as a project dependency?

I can depend on it.
 
> Can some modules be moved from cabal-install to Cabal library?

This is a really good question. Seems like exposing this kind of information 
could benefit some other people. 

I am not fimiliar with Cabal internals and have no idea whether this is 
possible nor the amount of work needed for this. I am trying to avoid digging
yet another rabbit whole for now.

[1]: https://hackage.haskell.org/package/cabal-helper

> On 25 July 2018 at 11:33, Félix Baylac <felix at alternativebit.fr> 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.