Re: Unix Dir for .hi Import Files

Ashley Yakeley
I'm not sure if there's any standardisation effort or intent for .hi files, or whether they are likely to remain GHC-specific for the forseeable future,
Each Haskell compiler has its own .hi format. An idea has been floated that there should be a standard 'minimal' .hi format, but it is not clear that it would be useful in practice, since the extra stuff the compiler normally puts in there must be for a reason.
but I was wondering if there should be a standard UNIX directory to put them in. For instance:
/usr/share/haskell-import/Org/Org/Semantic/HBase/Basic/Trivial.hi
...much like C has "/usr/include/".
This is very difficult, because not only does the .hi format vary between compilers, but even with GHC alone it is utterly dependent on the version of the compiler. Hence, GHC's .hi files must go in directories like /usr/local/lib/ghc-5.00.2/imports /usr/local/lib/ghc-5.02.3/imports etc. However, you can organise your own libraries as a 'package' if you like, and keep all the .hi files that belong with it together. The GHC documentation has more info on how to build a package. (Nhc98 has also adopted a simplified version of GHC' package mechanism, to appear in the next release.) Regards, Malcolm

on somewhat of a tangent, i was running into problems with where both nhc and ghc place their hi files when attempting to compile from a read-only filesystem, the standard autoconf setup (as used in DrIFT http://repetae.net/~john/computer/haskell/DrIFT) works almost perfectly except the .hi files always seem to be placed in the same directory as teh source files rather than with the .o files as would seem to make sense. This is necisarry when compiling from a read-only filesystem, or when building many binaries from one source tree with different tools or with different options. my current workaround is to add an explicit -i%srcdir% which does not solve the problem, but allows the build to continue in most cases. John On Sat, Jun 08, 2002 at 01:27:52PM +0100, Malcolm Wallace wrote:
Ashley Yakeley
writes: I'm not sure if there's any standardisation effort or intent for .hi files, or whether they are likely to remain GHC-specific for the forseeable future,
Each Haskell compiler has its own .hi format. An idea has been floated that there should be a standard 'minimal' .hi format, but it is not clear that it would be useful in practice, since the extra stuff the compiler normally puts in there must be for a reason.
but I was wondering if there should be a standard UNIX directory to put them in. For instance:
/usr/share/haskell-import/Org/Org/Semantic/HBase/Basic/Trivial.hi
...much like C has "/usr/include/".
This is very difficult, because not only does the .hi format vary between compilers, but even with GHC alone it is utterly dependent on the version of the compiler. Hence, GHC's .hi files must go in directories like
/usr/local/lib/ghc-5.00.2/imports /usr/local/lib/ghc-5.02.3/imports
etc.
However, you can organise your own libraries as a 'package' if you like, and keep all the .hi files that belong with it together. The GHC documentation has more info on how to build a package. (Nhc98 has also adopted a simplified version of GHC' package mechanism, to appear in the next release.)
Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

on somewhat of a tangent, i was running into problems with where both nhc and ghc place their hi files when attempting to compile from a read-only filesystem, the standard autoconf setup (as used in DrIFT http://repetae.net/~john/computer/haskell/DrIFT) works almost perfectly except the .hi files always seem to be placed in the same directory as teh source files rather than with the .o files as would seem to make sense.
Thanks. This is a very clear statement of a similar problem I was having when building a project with GHC. I don't recall all the details now but I remember having to fight rather hard to get GHC to place files in the right place and even harder to get GHC to generate Make-style dependency files containing the correct directories. In the end I think I settled on compromising the directory structure I wanted and writing a perl script which munged the generated dependency files. The fragility of this approach was demonstrated on the next release when a slight change in the format of one of the GHC-generated files threw my Makefile and script out of whack. Sorry I can't fill in details - this was about 18 months ago and the only records I have are some ugly-looking Makefiles. The point of my anecdote is just to add weight to the argument that this is an important issue to get right. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (3)
-
Alastair Reid
-
John Meacham
-
Malcolm Wallace