- Glasgow-haskell-users

RE: Preparing a Registered hc-file-bundle (Was Bootstrapping with HCfiles)
by Simon Marlow 14 Dec '05

14 Dec '05

On 13 December 2005 11:05, Andrew Walrond wrote: > On the HOST > ----------------- > > Unpack src tree, and cd into it. > > Configure with necessary options > $ ./configure --prefix=... > > Section 10.2.1'Cross-compiling to produce an unregisterised GHC' in > the build manual suggests creating an mk/build.mk with following > contents: GhcUnregisterised = YES > GhcLibHcOpts = -O -fvia-C -keep-hc-files > GhcRtsHcOpts = -keep-hc-files > GhcLibWays = > SplitObjs = NO > GhcWithNativeCodeGen = NO > GhcWithInterpreter = NO > GhcStage1HcOpts = -O > GhcStage2HcOpts = -O -fvia-C -keep-hc-files > SRC_HC_OPTS += -H32m > GhcBootLibs = YES > Reading between the lines somewhat, for a full registered version we > might need something like > GhcUnregisterised = NO > GhcLibHcOpts = -O -fvia-C -keep-hc-files > GhcRtsHcOpts = -keep-hc-files > GhcLibWays = > SplitObjs = NO > GhcWithNativeCodeGen = YES > GhcWithInterpreter = YES > GhcStage1HcOpts = -O > GhcStage2HcOpts = -O -fvia-C -keep-hc-files > SRC_HC_OPTS += -H32m > GhcBootLibs = YES > Advice on this bit gratefully received! This should be fine, except that you can leave out some of it - you probably want the default settings for GhcWithNativeCodeGen and GhcWithInterpreter, and the GhcUnregisterised should default to NO. > The manual next suggests copying some target generated include files > into the host ghc source, but since they are the same I guess we can > ignore that bit. > > Now building exactly as described in the manual: > > $ pushd glafp-utils && make boot && make && popd > $ pushd ghc && make boot && make && popd > > Manual suggests the build might fail in RTS, but probably not for our > registered version ? building the RTS should work, yes. > $ pushd libraries && make boot && make && popd > $ pushd ghc/compiler && make boot stage=2 && make stage=2 && popd > > $ pushd ghc/lib/compat > $ make clean > $ rm .depend > $ make boot UseStage1=YES > $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > $ popd > $ pushd ghc/utils > $ make clean > $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > $ popd > $ make hc-file-bundle Project=Ghc > > That should provide us with our hc-file-bundle, *-hc.tar.gz > > On the TARGET > -------------------- > > Unpack src tree, unpack the hc file bundle on top of it. > Cd into the src tree. > > Now it should be a simple matter of > $ distrib/hc-build --prefix=dir > $ make install Looks good! Cheers, Simon

1 0

Preparing a Registered hc-file-bundle (Was Bootstrapping with HC files)
by Andrew Walrond 13 Dec '05

13 Dec '05

Ok, so now we know its possible! Now the question is how to create and use a _registered_ hc file bundle. The Build manual describes the process of cross compiling an _unregistered_ hc file bundle, but has nothing to say about creating the simpler registered hc file bundle for the purpose of bootstrapping GHC on an equivalent supported platform but without a preinstalled ghc. So, reading between the lines a little, here is what I propose trying. Please take a look, and give me your thoughts if you think I am on the wrong track! HOST: Has ghc, happy, alex installed. TARGET: Same as host, but without ghc, happy alex. On the HOST ----------------- Unpack src tree, and cd into it. Configure with necessary options $ ./configure --prefix=... Section 10.2.1'Cross-compiling to produce an unregisterised GHC' in the build manual suggests creating an mk/build.mk with following contents: GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = NO GhcWithInterpreter = NO GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Reading between the lines somewhat, for a full registered version we might need something like GhcUnregisterised = NO GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = YES GhcWithInterpreter = YES GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Advice on this bit gratefully received! The manual next suggests copying some target generated include files into the host ghc source, but since they are the same I guess we can ignore that bit. Now building exactly as described in the manual: $ pushd glafp-utils && make boot && make && popd $ pushd ghc && make boot && make && popd Manual suggests the build might fail in RTS, but probably not for our registered version ? $ pushd libraries && make boot && make && popd $ pushd ghc/compiler && make boot stage=2 && make stage=2 && popd $ pushd ghc/lib/compat $ make clean $ rm .depend $ make boot UseStage1=YES $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ pushd ghc/utils $ make clean $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ make hc-file-bundle Project=Ghc That should provide us with our hc-file-bundle, *-hc.tar.gz On the TARGET -------------------- Unpack src tree, unpack the hc file bundle on top of it. Cd into the src tree. Now it should be a simple matter of $ distrib/hc-build --prefix=dir $ make install Any comments/suggestions before I give it a try? Thanks for all help so far, and in anticipation of more! Andrew Walrond

1 1

RE: GHC wish list.
by Simon Marlow 13 Dec '05

13 Dec '05

Hi Lemmih, Might be a good idea to add these as feature requests: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Cheers, Simon On 13 December 2005 15:17, Lemmih wrote: > I've been using the GHC library in hIDE and HASP for some time now and > there are a few things I'd love to see implemented: > > * Changeable lexer/parser (just like DynFlags.log_action) > Not very important but it would be convenient in HASP. > * Cabalization of the library. > Not having a profiling version of the library and not being able to > rebuild it easily is a bit limiting. > * GHCi compatibility. > hIDE is currently using ghc-api[1] because the real library exports > symbols that clashes with GHCi.

1 0

GHC wish list.
by Lemmih 13 Dec '05

13 Dec '05

Hiya, I've been using the GHC library in hIDE and HASP for some time now and there are a few things I'd love to see implemented: * Changeable lexer/parser (just like DynFlags.log_action) Not very important but it would be convenient in HASP. * Cabalization of the library. Not having a profiling version of the library and not being able to rebuild it easily is a bit limiting. * GHCi compatibility. hIDE is currently using ghc-api[1] because the real library exports symbols that clashes with GHCi. -- Friendly, Lemmih [1] ghc-api: http://scannedinavian.com/~lemmih/ghc-api

1 0

RE: Bootstrapping with HC files
by Simon Marlow 13 Dec '05

13 Dec '05

On 12 December 2005 18:21, Andrew Walrond wrote: > 3) Why don't you guys supply hc tarballs for bootstrapping on common > platforms? They would seem to be rather more versatile than the usual > rpms and binary tarballs. A couple of reasons, neither of which is very convincing: 1. the HC files are sensitive to platform differences, so I'm not sure that HC files generated for one flavour of Linux would necessarily work on other flavours, for example. 2. building from HC files isn't well supported, and tends to be rather fragile, so we don't like to encourage it. The reason it isn't well supported is just lack of time. Cheers, Simon

1 0

RE: Bootstrapping with HC files
by Simon Marlow 13 Dec '05

13 Dec '05

On 12 December 2005 22:47, Donald Bruce Stewart wrote: > andrew: >> I run a source based linux distro called Heretix, and I want to make >> a ghc package which will install with or without an existing ghc. At >> the moment, we supply a binary-ghc package, whch is a prerequisite >> of the from-source ghc package. >> >> It seems to me that I can prepare HC tarballs for my target >> platforms (x86, x86_64) which will remove the need for the >> ghc-binary package. My questions: >> >> 1) Can I produce 'registered' hc files? The build manual bangs on >> about cross compiling unregistered hc files, which isn't really what >> I need. >> >> 2) Would a ghc built from registered hgc files every bit as good and >> complete as a normally bootstrapped ghc? > > Yes, the OpenBSD versions of GHC build from registerised .hc tar > balls. It's fast. > > If you're interested in this path, check out: > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That port is for 6.2.2 - do you have a 6.4.1 port too? Many thanks for keeping the .hc bootstrapping route working, BTW. It's a great help. Cheers, SImon

1 0

Bootstrapping with HC files
by Andrew Walrond 13 Dec '05

13 Dec '05

I run a source based linux distro called Heretix, and I want to make a ghc package which will install with or without an existing ghc. At the moment, we supply a binary-ghc package, whch is a prerequisite of the from-source ghc package. It seems to me that I can prepare HC tarballs for my target platforms (x86, x86_64) which will remove the need for the ghc-binary package. My questions: 1) Can I produce 'registered' hc files? The build manual bangs on about cross compiling unregistered hc files, which isn't really what I need. 2) Would a ghc built from registered hgc files every bit as good and complete as a normally bootstrapped ghc? If 1) and 2) then 3) Why don't you guys supply hc tarballs for bootstrapping on common platforms? They would seem to be rather more versatile than the usual rpms and binary tarballs. Thanks in advance! Andrew Walrond

4 5

Project options for GHC
by Iavor Diatchki 12 Dec '05

12 Dec '05

Hello, I have been using the .ghci file with GHCi to set global options for my project and I find it very useful. The kind of options I put there are: where to put .hi/.o files, what warnings to produce, where to look for code. etc. It works great. I was thinking that it would be very convenient to have the same ability when using 'ghc --make', because at the moment I have a number of the same options duplicated in my Makefile. Also, often I find myslef wanting to compile just one file (and all of its dependents), because GHCi tends to be a bit slow at compiling things, but is quite fast at loading object code. I can do this using 'ghc --make', but I also need to specify all the additional project options. I realize that I can achieve what I want with a little shell script, but a ghc-supported configuration file would be more portable and simpler to use. -Iavor

2 1

RE: recommended build system
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 18:49, Frederik Eaton wrote: > $ ghc -pgml gcc -pgmP "gcc -E -undef -traditional" -pgmc gcc --make > Matrix.hs -o matrix Chasing modules from: Matrix.hs > [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) > ghc-6.5.20051208: could not execute: gcc-3.4.3 > > Maybe a more informative error message would be a useful feature as > well. Sorry, also add -pgma gcc. (or wait for tonight's build, which won't have gcc-3.4.3 hardwired). If it still complains, send us the -v output. Cheers, Simon > Frederik > > On Mon, Dec 12, 2005 at 02:28:34PM -0000, Simon Marlow wrote: >> On 10 December 2005 05:08, Frederik Eaton wrote: >> >>> $ ghc -pgmc gcc --make Matrix.hs -o matrix >>> Chasing modules from: Matrix.hs >>> [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) >>> ghc-6.5.20051208: could not execute: gcc-3.4.3 >>> >>> Hard-coding things is ... not ... nice ... >> >> You also need -pgml gcc, and probably -pgmP "gcc -E -undef >> -traditional". >> >> Cheers, >> Simon

2 1

RE: recommended build system
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 05:08, Frederik Eaton wrote: > $ ghc -pgmc gcc --make Matrix.hs -o matrix > Chasing modules from: Matrix.hs > [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) > ghc-6.5.20051208: could not execute: gcc-3.4.3 > > Hard-coding things is ... not ... nice ... You also need -pgml gcc, and probably -pgmP "gcc -E -undef -traditional". Cheers, Simon

2 1