When I try to build Yhc, I get this: gcc -o inst/bin/yhi src/runtime/BCKernel/external.o src/runtime/BCKernel/hashtable.o src/runtime/BCKernel/heap.o src/runtime/BCKernel/hsffi.o src/runtime/BCKernel/info.o src/runtime/BCKernel/integer.o src/runtime/BCKernel/iofuncs.o src/runtime/BCKernel/jonkers.o src/runtime/BCKernel/main.o src/runtime/BCKernel/make.o src/runtime/BCKernel/mark.o src/runtime/BCKernel/module.o src/runtime/BCKernel/mutator.o src/runtime/BCKernel/pretty.o src/runtime/BCKernel/primitive.o src/runtime/BCKernel/sanity.o src/runtime/BCKernel/stopcopy.o src/runtime/BCKernel/profile.o src/runtime/BCKernel/foreign.o src/runtime/BCKernel/process.o src/runtime/BCKernel/thread.o src/runtime/BCKernel/stable.o src/runtime/BCKernel/builtin/Concurrent.o src/runtime/BCKernel/builtin/Array.o src/runtime/BCKernel/builtin/FFI.o src/runtime/BCKernel/builtin/IO.o src/runtime/BCKernel/builtin/Prelude.o src/runtime/BCKernel/builtin/PackedString.o src/runtime/BCKernel/builtin/RuntimeAPI.o src/runtime/BCKernel/builtin/System.o depends/ctypes/libffi/src/prep_cif.o depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/x86/ffi.o depends/ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -lgmp -lm -lpthread -ldl YHC_build(["src/packages/yhc-base-1.0/Data/Ix.hbc"], ["src/packages/yhc-base-1.0/Data/Ix.hs"]) inst/bin/yhc -i src/packages/yhc-base-1.0/ -d src/packages/yhc-base-1.0/ -c src/packages/yhc-base-1.0/Data/Ix.hs Compiling Data.Ix ( src/packages/yhc-base-1.0/Data/Ix.hs ) Copy("inst/lib/yhc/packages/yhc-base/1.0/Data/Ix.hi", "src/packages/yhc-base-1.0/Data/Ix.hi") YHC_build(["src/packages/haskell98-1.0/Ix.hbc"], ["src/packages/haskell98-1.0/Ix.hs"]) inst/bin/yhc -i src/packages/haskell98-1.0/ -d src/packages/haskell98-1.0/ -c src/packages/haskell98-1.0/Ix.hs yhc: Error: File not found, Data.Ratio Reason: imported from Ix Looked in: /home/naesten/hacking/haskell/yhc-devel/src/packages/haskell98-1.0/ /home/naesten/hacking/haskell/yhc-devel/inst/lib/yhc/packages/yhc-base/1.0 I can't figure out why Yhc thinks that Ix imports Data.Ratio, because it sure doesn't seem to! The SConscript files for haskell98-1.0 and yhc-base-1.0 are quite bewildering... why is there so much in them anyway? I might like to set up a buildbot, though I don't have much CPU or RAM...
Hi
I can't figure out why Yhc thinks that Ix imports Data.Ratio, because it sure doesn't seem to!
Everything imports Data.Ratio, because its used for desugaring rational numbers. Scons has a large number of dependancies, but not all of them, so sometimes random disk listings give wrong orders, and requires an extra Scons annotation. I think this is the case here, and Andrew should be able to fix this quite easily tomorrow.
The SConscript files for haskell98-1.0 and yhc-base-1.0 are quite bewildering... why is there so much in them anyway?
There is no dependancy analysis, all the info is baked in the Scons file. Its possible we can move to using Yhc.Make once thats done - I've filed bug 31.
I might like to set up a buildbot, though I don't have much CPU or RAM...
That's not a problem - as long as you heavily nice the buildbot, it shouldn't interfere with your work, and if it takes a really really really long time to build, thats irrelevant to the buildbot - the Linux PPC takes forever to build, but its still a really useful test! Thanks Neil
Neil Mitchell
Hi
I can't figure out why Yhc thinks that Ix imports Data.Ratio, because it sure doesn't seem to!
Everything imports Data.Ratio, because its used for desugaring rational numbers. Scons has a large number of dependancies, but not all of them, so sometimes random disk listings give wrong orders, and requires an extra Scons annotation. I think this is the case here, and Andrew should be able to fix this quite easily tomorrow.
So, why doesn't it just build (and copy into inst) one package first and then the other? Wouldn't that make things simpler?
On 9/19/06, Samuel Bronson
So, why doesn't it just build (and copy into inst) one package first and then the other? Wouldn't that make things simpler?
No, that'd actually make things more complicated. At the moment Scons built in dependency tree decides what order to build things. By doing something like that we'd be shoe-horning our own dependency tree on top of the build in one. I've added a new dependency in that should hopefully fix the problem you've experienced. I can't wait for Yhc make mode to be complete so all this nonsense will stop. Andrew
participants (3)
-
Andrew Wilkinson -
Neil Mitchell -
Samuel Bronson