Re: GHC include files
"Manuel M. T. Chakravarty" wrote: This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. On the other hand, wrapping it into the ghc command will make a version mismatch when someone moves files around slightly less likely.
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . .
Re: GHC include files
It seems that the choice of the installation path depends more on religious thoughts than technical necessities. The only thing I was trying to say is that Joe User rarely needs 5 different versions of GHC at the same time, so I prefer paths without version numbers for my RPMs. Of course it makes sense for advanced GHC hackers to have different versions lying around, but those people normally build GHC from source anyway. And with the configure stuff relocating GHC is a piece of cake, e.g. with ./configure --prefix=/usr --libdir=/usr/lib/ghc binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's the problem? :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: GHC include files
George Russell [EMAIL PROTECTED] wrote, "Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . . This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. Manuel
RE: GHC include files
Don't know about binary dists, but I compiled 4.06 from source and it did install directly in /usr/local/lib, which is IMHO not so good. Many files used by a single package should generally go to a separate subdirectory. I reran ./configure with some option to install in /usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib. I think on reflection that /usr/local/lib/ghc or /usr/local/lib/ghc-4.06 would be a better choice than /usr/local/lib. In fact, binary distributions already use the latter. Include files, on the other hand, should really be in /usr/local/include/ghc, so f.e. #include ghc/RtsAPI.h has a chance of working. BTW, I see lack of standard way of conveniently installing a Haskell library. For example c2hs installs in its own subdirectory and provides a script c2hs-config which outputs compiler and linker flags necessary to link an application with c2hs libs. OK, but should every package provide its own script? I don't think so. Also, I don't think we should adopt a solution that requires the programmer to know anything about how or where a particular library is installed. I had in mind a slight generalisation of GHC's syslib mechanism. Currently GHC's libraries (HsLibs) are split into about 7 categories, and you can bring a given category into scope by saying, eg. '-syslib text' on the command line. GHC knows about dependencies between libraries, so you don't need to say '-syslib lang' as well, if text depends on lang. The ordering is also unimportant. What we need is a way for external library writers to be able to package up and distribute a library that will install onto a system with an existing GHC such that you can say '-syslib blah' to get the new library. This is pretty straightforward, we just need to separate out the syslib configuration stuff from the driver, and write a (perl?) script to do the installation. The script would be part of GHC, and invoked as part of the library installation. In the long term, I hope Haskell will get a hiearchical module namespace and we can do away with the -syslib option altogether. We're also working towards expanding the library collection to be a lot more comprehensive; we've now incorporated HaXml, for instance. Simon Marlow has already explained why shared libraries are currently impossible... A pity. Hope that at some time someone will anyway do them, possibly not using standard Unix linker if problems are specifically with it itself rather than with the concept. Good news on this front: due to a truly heroic effort on the part of Julian, STG-Hugs is just about able to load GHC-compiled modules, which means you can compile Main.hs into Main.o, and run it inside STG-Hugs against the compiled prelude/libraries etc. Strictly speaking it's dynamic linking, not shared libraries, but you still get the disk-space and link-time savings. If the linker were separated out from Hugs and included in GHC's RTS, we'd have a way to generate standalone dynamically-linked binaries. Cheers, Simon
Re: GHC include files
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared between lots of machines and there is no question of my installing GHC in /usr/bin or anything like it. (The few system adminstrators here are all honest, overworked, and sadly incorruptible.) My original problem was that GHC installs the include files in prefix/lib/ghc-4.06/includes meaning you have to know the version number as well as the prefix. I suppose this makes sense where prefix is in fact /usr, but I actually make prefix depend on the version, so having to specify the version twice is redundant. At least my scheme means that (on the rare times when I can build from source . . .) I can store multiple CVS releases.
RE: GHC include files
Just a few remarks and personal opinions from a RPM builder's view:
* IMHO the whole /usr/local hierarchy is completely obsolete for
and "real" programs should only be used for quick local hacks.
= GHC should reside under /usr/{bin,lib,include}
I'd rather say that the use of /usr/local is system dependent. The BSD
folks for example have a nice clear scheme: everything in /usr is part of
the base system, everything in /usr/local comes from the ports tree.
In a package system the choice of installation directories is moot, as you
point out. The only issue is whether several versions are allowed to
co-exist. Either choice seems reasonable to me.
Cheers,
Simon
Re: GHC include files
Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I think this is a reasonably straightforward means to allow hierarchical library organisation. Plus, as of about two weeks ago, nhc98 (in CVS) implements something similar to this feature. However, -i / -I only covers imports, it doesn't cover linking. Hence, I also propose to extend the -L flag in the same way. -Ldir usually adds a relative or absolute directory to the link search path, so the same extension would allow "-Ldata/edison -ledison" to search for both ./data/edison/libedison.a and $prefix/data/edison/libedison.a. The disadvantage of this scheme is that you can get into trouble as soon as you (accidentally) name one of your local directories the same as one of the system directories. With system directories like `posix', `lang', `num', `net', etc a collision is only a matter of time, I think. Cheers, Manuel
RE: GHC include files
Simon Marlow [EMAIL PROTECTED] wrote, Don't know about binary dists, but I compiled 4.06 from source and it did install directly in /usr/local/lib, which is IMHO not so good. Many files used by a single package should generally go to a separate subdirectory. I reran ./configure with some option to install in /usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib. I think on reflection that /usr/local/lib/ghc or /usr/local/lib/ghc-4.06 would be a better choice than /usr/local/lib. In fact, binary distributions already use the latter. I like the use of a prefix including the program name and version number very much, as I usually have about three versions of ghc installed (the latest stable release, the stable release before that, and the current cvs version). I understand Sven's position on that matter, but only because some packages make a mess out of the installation doesn't mean that we can't find a nice way to let different versions co-exist. Include files, on the other hand, should really be in /usr/local/include/ghc, so f.e. #include ghc/RtsAPI.h has a chance of working. That is indeed a problem. BTW, I see lack of standard way of conveniently installing a Haskell library. For example c2hs installs in its own subdirectory and provides a script c2hs-config which outputs compiler and linker flags necessary to link an application with c2hs libs. OK, but should every package provide its own script? I don't think so. Also, I don't think we should adopt a solution that requires the programmer to know anything about how or where a particular library is installed. I had in mind a slight generalisation of GHC's syslib mechanism. Currently GHC's libraries (HsLibs) are split into about 7 categories, and you can bring a given category into scope by saying, eg. '-syslib text' on the command line. GHC knows about dependencies between libraries, so you don't need to say '-syslib lang' as well, if text depends on lang. The ordering is also unimportant. I will still have to use `c2hs-config'[1]. The point of `c2hs-config' is to provide a truely OS and compiler system-independent way of using C-HS. So, unless the Haskell language definition enforces a fixed policy on library organisation, the need for `c2hs-config' won't go away. In fact, the concept behind `c2hs-config' is not my own idea. It is the mechanism used by the GTK+ and Gnome libraries - ie, even C libraries run into essentially the same problems as we do. There are quite a number of subtleties involved here: * How do I get the version of a library? (I just use `c2hs-config --version'.) * How can I have two versions of the same library installed? (With `c2hs-config' they can be installed with different prefixes.) * How can I select between different versions of one library? Eg, how can I have ./configure --cool-lib=whichever style options in a program using the library. (With `c2hs-config', you just provide the path to the c2hs-config script you want - the script knows the rest.) * How can I handle multi-language programs/libraries (eg, mixed C and Haskell code)? (The `...-config' script gets different flags for the different languages involved.) * How can I select between different capabilities of my library (with or without threads or so)? (`gtk-config' is called with or without the `gthread' argument). I don't know of any other configuration mechanism that handles all these things gracefully. Cheers, Manuel [1] For those who don't know how `c2hs-config' works: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.1
Re: GHC include files
On Tue, Feb 29, 2000 at 17:06:01 +, Marcin 'Qrczak' Kowalczyk wrote:
BTW, I see lack of standard way of conveniently installing a Haskell
library. For example c2hs installs in its own subdirectory and provides a
script c2hs-config which outputs compiler and linker flags necessary to
link an application with c2hs libs. OK, but should every package provide
its own script?
At least, the idea is flexible and those scripts are easily adaptable...
Putting C headers in a standard place like /usr/include or
/usr/local/include and C libraries in /usr/lib is convenient.
Not a good idea, if there is more than one version of a software installed
on a system...
IMHO there should be a flag similar to -syslib which tells the compiler
and linker to use a package of a given name from such standard
directory (hoping that there will be no name clashes): search for
interfaces there and link a library. Not depending on whether it is
under /usr/lib or /usr/local/lib - packages themselves should not be
required to separately announce where they reside.
It's possible that a package requires some additional compiler flags when
it is used.
the "script" solution addresses this problem, too...
(cf. `xxx-config--libs')
Will ghc change interface format with each version? :-)
This is the biggest problem (and, interestingly, the least addressed :-)).
Especially for binary distribution builders, it's quite inconvenient to
rebuild every GHC-library on the system to match with the latest compiler
version :-(
I thought about a scheme similar to the tex-font generation (if the font is
"compiled" for a particular resolution (dpi), it's re-used; if not, it is
created).
[I'll describe that in another mail...]
On Wed, Mar 01, 2000 at 04:34:43 -0800, Simon Marlow wrote:
What we need is a way for external library writers to be able to package up
and distribute a library that will install onto a system with an existing
GHC such that you can say '-syslib blah' to get the new library. This is
pretty straightforward, we just need to separate out the syslib
configuration stuff from the driver, and write a (perl?) script to do the
installation. The script would be part of GHC, and invoked as part of the
library installation.
This would not address the .hi-file versionitis...
And what, if the library needs additional compiler flags?
On Wed, Mar 01, 2000 at 14:29:41 +0100, Sven Panne wrote:
Just a few remarks and personal opinions from a RPM builder's view:
* IMHO the whole /usr/local hierarchy is completely obsolete for
and "real" programs should only be used for quick local hacks.
= GHC should reside under /usr/{bin,lib,include}
... and the GNU/Hurd people try to obsolete the /usr tree IIRC :-)
... and there is the /opt tree (for big packages) ...
quoting FHS-pre2.1#4.6 "/usr/local : Local hierarchy":
[...]
This directory should always be empty after first installing a FHS-
compliant system. No exceptions to this rule should be made other than
the listed directory stubs.
Locally installed software should be placed within /usr/local rather
than /usr unless it is being installed to replace or upgrade software in
/usr.
[...]
So, /usr/local is perfectly ok for software that is not installed via a
package management system and should be the default for a source dist or
binary-tarballs[2].
[2] a single tarball bindist is _NO_ package management! (Go away,
slackware users! :-))
There is no single solution... that's one of the reasons, why autoconf
exists, right? :-) (Hi Sven, Manuel!) :-))
Include files, on the other hand, should really be in
/usr/local/include/ghc, so f.e. #include ghc/RtsAPI.h has a chance of
working. [...]
I'd favour a scheme, in which ghc can tell me, where the include files
reside: the perl driver already knows about the location, so why not adding
an option: `ghc --print-includedir'?
This would also be the cleanest solution, if there is more than one version
of ghc installed...
Honestly, if a project has more than two source files, I let `make' care
about dependencies etc. and
GHCINCLUDES := $(shell $(HC) --print-includedir)
[...]
%.o: %.hs
$(HC) $(GHCINCLUDES) $(MOREOPTIONS) $ -o $@
is not very complicated, is it?
On Wed, Mar 01, 2000 at 07:59:25 -0800, Simon Marlow wrote:
In a package system the choice of installation directories is moot, as you
point out. The only issue is whether several versions are allowed to
co-exist.
There is also the possibility to have more than one _flavour_ of a specific
version installed, for example ghc-4.06 and ghc-4.06-debugging...
Cheers,
Michael
p.s.: I'm just browsing through my overflowing mail folders, sorry if I
miss some of the messages...
--
Lehrstuhl-Gärtnerei Michael Weber [EMAIL PROTECTED]
Lehrstuhl für Informatik II
RWTH Aachen
WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
GHC include files
The latest binary distribution puts the GHC include files in "lib/ghc-4.06/includes", not "lib/includes" as older versions used to. This is a nuisance, because it means that there isn't any way a Makefile can refer to the includes without coding in the GHC version. Or is there? One needs access to the include files to get at, for example, Stg.h
RE: GHC include files
The latest binary distribution puts the GHC include files in "lib/ghc-4.06/includes", not "lib/includes" as older versions used to. This is a nuisance, because it means that there isn't any way a Makefile can refer to the includes without coding in the GHC version. Or is there? One needs access to the include files to get at, for example, Stg.h I wasn't aware that anything had changed; perhaps you used to use 'make install' instead of a binary distribution? You're right, for certain things you might need to get at the include files, so they should be in a more standard place. Like /usr/local/include/ghc, or something. Cheers, Simon
Re: GHC include files
Maybe there should be a standard place to put Haskell interfaces and libraries/objects. As there can be many modules in a package and thus many interfaces, and collisions between module names are harmless in a case where both are not used in the same program, interfaces should probably go to a separate directories for each package. Yes, yes, yes!! It might be worth considering something like Perl's system: the user/administrator sets an environment variable giving a search path for libraries, and includes something like $HOME/lib/site_perl or /usr/local/lib/perl. When a program requests a module, it is searched for in the appropriate subtree of all the directories listed in this variable (plus the standard places). Of course, Perl has a hierarchical namespace for modules, rather than a flat one, so conflicts are a little less likely; but this could still be useful anyway. JAP\010HH... --KW 8-) -- : Keith Wansbrough, MSc, BSc(Hons) (Auckland) ---: : PhD Student, Computer Laboratory, University of Cambridge, UK. : : Native of Antipodean Auckland, New Zealand: 174d47'E, 36d55'S. : : http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] : ::
