GHC (API?) question: GHC Core for Base libraries

[Brandon Allbery]

It's more complicated than that, because unless your'e just doing some
transient experimentation this will bite you over and over. What you'll
want to do is check the stage during compilation (it should be available as
macros via the CPP extension) and disable the plugin for stage 1. Then (I
think; it's even worse if not...) use the base built during stage 2.

The comlication there being that it may use the stage 1 compiler to build
the stage 2 base. In this case, you probably can't e.g. get this integrated
into ghc, because it has to be possible to get it in stage 1 and ideally
stage 2 (some platforms can't do stage 2 builds yet; ARM at least used to
be in this category, hence e.g. no ghci or TH). Which places limits on what
features can be used in the base package.

On Tue, Dec 4, 2018 at 1:37 PM Bill Hallahan <william.hallahan at yale.edu>
wrote:

> Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is
> a good example of using a vanilla ghc installation to compile standard
> libraries like base.
>
> Thanks Cheng, this looks interesting and helpful!  I'm still trying to
> understand it fully, but it seems like the important pieces for building
> base are in the boot and Setup scripts?
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> Thanks Brandon.  Is there a recommended/documented way to build base with
> a stage 2 compiler?  I haven't been able to find anything about this on the
> wiki.
>
> On Dec 3, 2018, at 11:10 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks
> support for the bytecode backend used by TH, plugins, ghci, etc. A base
> build with a stage 2 compiler should work.
>
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <william.hallahan at yale.edu>
> wrote:
>
>> Hi,
>>
>> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm
>> using the GHC API to get Core from .hs files.  I'd like to be able to run
>> this analysis on the standard libraries that come with GHC, which requires
>> getting those as Core.
>>
>> Unfortunately, the build process for these libraries is not entirely
>> straightforward, and relies on a make script.  I eventually came up with
>> the plan of writing a GHC plugin, which, rather than performing any
>> optimizations, would simply run the analysis, and then print the results
>> out to a file.  I was able to write the plugin successfully, and test it on
>> several files that were *not* from the base library.
>>
>> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
>> the make script would call the plugin.  I ended up with the following:
>>
>> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
>> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
>> -package hplugin -fplugin HPlugin.Plugin -v
>>
>> The two package databases are to get to (1) the GHC API and (2) the
>> plugin ("hplugin") itself.  With this I get an error message, which I have
>> not been able to find a way to resolve:
>>
>> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
>> -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
>> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
>> -ilibraries/ghc-prim/dist-install/build/autogen
>> -Ilibraries/ghc-prim/dist-install/build
>> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
>> -optP-include
>> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
>> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
>> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
>> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
>> hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts
>> -Wno-trustworthy-safe -Wno-deprecated-flags
>> -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build
>> -hidir libraries/ghc-prim/dist-install/build -stubdir
>> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c
>> libraries/ghc-prim/./GHC/Types.hs -o
>> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
>> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
>> <command line>: not built for interactive use - can't load plugins
>> (HPlugin.Plugin)
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
>> make: *** [all] Error 2
>>
>> So I'm now wondering (an answer to either of these two questions would be
>> helpful):
>> (1) Is this a viable path?  That is, is it possible to use a plugin when
>> building Base?  If so, does anyone know what I might be doing wrong/what
>> could be causing this error message?
>> (2) Is there some other better/easier way I could get Core
>> representations of the standard libraries?  I guess, in theory, it must be
>> possible to compile the standard libraries with the GHC API, but I have no
>> idea how/where to look to figure out how?
>>
>> Thanks,
>> Bill
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
>
>

-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181204/aa3ddd6b/attachment.html>