On Tue, Feb 29, 2000 at 17:06:01 +0000, 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/
