
I have trouble understanding the relationship between the .hi file below nhc98/include/ and the ones of the same name generated during the build process (below nhc98/src/prelude, IIRC). Could somebody please enlighten me? My concrete problem is that I've changed CTypesExtra (types => newtypes and added quite a few instances), but the changes don't seem to have any effect for the nhc98 which is being built. :-( Cheers, S.

Sven Panne
I have trouble understanding the relationship between the .hi file below nhc98/include/ and the ones of the same name generated during the build process (below nhc98/src/prelude, IIRC). Could somebody please enlighten me?
The .hi files in include/ for the standard prelude and libraries are static. They are not recreated or overwritten during the build process. This is partly because they are needed to bootstrap the build, and partly because there are some special hand-tweaks to these versions of the files (some for performance, some possibly also to avoid bugs). Think of them as being like ghc's .hi-boot files. By contrast, those for the hierarchical libs (under include/packages/) are indeed copied directly during the build.
My concrete problem is that I've changed CTypesExtra (types => newtypes and added quite a few instances), but the changes don't seem to have any effect for the nhc98 which is being built. :-(
You can probably just copy the relevant file (Foreign.hi?) to the include directory, and check it into CVS if it works. Regards, Malcolm

Malcolm Wallace wrote:
[...] Think of them as being like ghc's .hi-boot files. [...]
Well, this concept would be OK if we reached a fixed point after nhc98 itself has been built, but doing mysterious things by hand is, well, a kind of sub-optimal... :-( I'll do some experiments and check in FFI.hi when nhc98 itself and the libraries can be built. This should definitely be automated somehow.... Cheers, S.

Sven Panne
Malcolm Wallace wrote:
[...] Think of them as being like ghc's .hi-boot files. [...]
Well, this concept would be OK if we reached a fixed point after nhc98 itself has been built, but doing mysterious things by hand is, well, a kind of sub-optimal... :-(
Unfortunately, a true fixpoint is probably impossible. When a module is permitted to redefine entities from the stdlibs, as indeed the stdlibs must allow when bootstrapping, nhc98 appears to re-order the entities recorded in the .hi file. So, it would be possible to end up simply juggling the order endlessly. Given that these files must reside in CVS, I don't fancy the confusion that might result from continual auto-regeneration of versions that differ only in a surface way. But I take the general point that this makes life somewhat tricky for the novice nhc98-developer... And perhaps using a separate file nomenclature like .hi-boot would be a good solution. Regards, Malcolm
participants (2)
-
Malcolm Wallace
-
Sven Panne