HDirect installation
Sigbjorn's latest patches for HDirect seem to get rid of the
stdcall/_stdcall/__stdcall confusion, but the installation is still
overly complicated, see e.g. the attached hdirect.spec. It would be
nice if every FOO \elem {ghc,happy,green-card,hdirect} could be built
and installed generically via:
autoheader
autoconf
./configure
make ProjectsToBuild="glafp-utils FOO" boot
make ProjectsToBuild="glafp-utils FOO" all
make ProjectsToInstall=FOO install
Happy almost manages this, except for the documentation. Perhaps one
should add a doc target?
make ProjectsToBuild="glafp-utils FOO" doc
Another point is the automatic extraction of version numbers from
the sub-packages. Green Card and HDirect currently don't define a
ProjectVersion in their mk/version.mk. This would be quite handy for
the automatic construction of source tar files from CVS sources,
see e.g. my ugly hack for this attached to this mail.
Perhaps one day we can simply type "make ghc-rpm"... *sigh* :-)
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
Vendor: Z101-Solutions, Munich, Germany
Distribution: Softies
Name: hdirect
Version: 0.15
Release: 2
Copyright:GPL
Group:Development/Languages/Haskell
Packager: [EMAIL PROTECTED]
URL: http://www.dcs.gla.ac.uk/fp/software/hdirect/
Source:
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/hdirect/hdirect-0.15-src.tar.gz
Requires: haskell
Summary: An IDL Compiler for Haskell
%description
HaskellDirect is an IDL compiler for Haskell, helping the Haskell
programmer to better interact with and reuse external code.
Interfacing Haskell code to external code involves the conversion of
values between the Haskell world and the outside, as data representations
and details of how memory is managed, are worlds apart at times. Manually
writing the boilerplate code that takes care of this conversion is about
as exciting as watching grass grow and, as a result, error prone.
Using an Interface Definition Language (IDL) as basis, HaskellDirect
automates the generation of such impedance matching code, generating the
necessary marshaling code to interface to external functions (and vice
versa.)
With IDL, the functionality provided by a programming interface is
specified in a programming language neutral framework. The HaskellDirect
IDL compiler converts this specification into a set of method stubs.
Depending on how the compiler is invoked, these stubs can be used to:
* Call upon external functions from within Haskell,
* Let external code call upon Haskell functions,
* Call COM (Microsoft's Component Object Model) methods from Haskell,
* Create COM method wrappers,
The HaskellDirect IDL compiler currently groks both the OSF DCE
dialect of IDL (including the various extensions introduced by the
Microsoft IDL compiler) and the OMG IIOP/CORBA dialect. (Only the
former can be used for describing COM interfaces.)
Author:
---
Sigbjorn Finne <[EMAIL PROTECTED]>
%prep
%setup -n fptools
%build
test -z "${HC}" && HC="ghc -O -H90m"
autoheader
autoconf
./configure
make ProjectsToBuild=glafp-utils boot
make ProjectsToBuild=glafp-utils all
make -C hdirect/src mkVersion
make -C hdirect/src HC="$HC" boot
make -C hdirect/src HC="$HC" all
make -C hdirect/lib HC="$HC" boot
make -C hdirect/lib HC="$HC" all
make -C hdirect/doc {hdirect,primitive,user}.{dvi,ps,html}
%install
cd hdirect
install -s src/ihc /usr/bin
install lib/libhdirect.a /usr/lib
install -d /usr/lib/hdirect
install -m 0644 lib/HDirect.hi lib/HDirect.lhs lib/Pointer.hi lib/Pointer.lhs
lib/PointerPrim.hi lib/PointerPrim.hs lib/PointerPrim.hs lib/PointerSrc.c
lib/PointerSrc.h /usr/lib/hdirect
cd ..
%files
%doc hdirect/distrib/ANNOUNCE
%doc hdirect/distrib/INSTALL
%doc hdirect/distrib/LICENSE
%doc hdirect/distrib/README
%doc hdirect/NEWS
%doc hdirect/Notes
%doc hdirect/ToDo
%doc hdirect/doc/
%doc hdirect/examples/
/usr/bin/ihc
/usr/lib/libhdirect.a
/usr/lib/hdirect
#!/bin/bash
buildtar () {
SUBDIR="$1"
PREFIX="$2"
VERSION="$3"
VMK="fptools/${SUBDIR}/mk/version.mk"
if test -z "${VERSION}" -a -r ${VMK} ; then
VERSION="$(grep '^ProjectVersion[ \t]*=[ \t]*[0-9.]*$' ${VMK} | \
sed 's/^[^0-9]*\([0-9.]*\).*$/\1/')"
fi
if test -z "${VERSION}" ; then
echo "* ERROR: No version found for ${SUBDIR} *"
exit 1
fi
TARFILE="${PREFIX}-${VERSION}-src.tar.gz"
echo "* Building ${TARFILE} for ${SUBDIR} *"
TAR="tar -c -z --exclude=CVS --exclude=.cvsignore"
for EXCLUDE in CONTRIB common-rts ghc green-card haggis \
happy hdirect hslibs literate nofib ; do
test
Re: Preprocessor question
Michael Weber wrote: > [...] maybe the *BSD, OSF, and Windows folks should do the above > tests, too... This seems to work on Alphas, too: -- $ uname -srm OSF1 V3.2 alpha $ echo TEST | gcc -E -DTEST=works - # 1 "" works $ echo TEST | /lib/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/bin/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/ucb/cpp -DTEST=works - # 1 "" works -- $ uname -srm OSF1 V4.0 alpha $ echo TEST | gcc -E -DTEST=works - # 1 "" works $ echo TEST | /lib/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/bin/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/ucb/cpp -DTEST=works - # 1 "" works -- 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: Preprocessor question
On Tue, Jul 13, 1999 at 17:47:27 +0900, Manuel M. T. Chakravarty wrote: > Simon Marlow <[EMAIL PROTECTED]> wrote, > It isn't strictly speaking hardcoded, it's set up when you configure a binary distribution. So if you move gcc or install a new version, you need to re-install ghc. Yes, and that's a thing which should not happen: one installs a new package and mysteriously other packages begin to break... :-( Even worse: consider this being done by the admin or automatically, i.e. where problem resolution isn't simple... >>> I am sure that it is clear that a binary distribution with strict >>> dependencies on locations of other tools is far from ideal. That's exactly why I wrote the original message :-) > > This probably isn't the case for RPM's, but as you noted in your message > > it's up to the package builder to arrange for the location of cpp and other > > tools to be configured at install time. >>> [...] it would be nice if the path (and any other similar dependencies) >>> where located in a dedicated file where they are easy to find and patch. > > One possibility would be to have a `ghc-cpp' script, which is a one liner > and just `exec's cpp. We could either patch this script or have different > versions `ghc-cpp-', which are linked to `ghc-cpp'. What do you > think? *hmm* IMHO we already have one: 'hscpp'. As I said, ghc doesn't make use of $RAWCPP, and mkdependHS could use hscpp instead of calling cpp directly. Besides, SimonM mentioned that 'gcc -E' is a Bad Thing. I tried CPPs from gcc-2.7.2.3, gcc-2.8.1 and egcs-2.91.66, and they do accept input from stdin (note the dash): == $ echo TEST|gcc -E -DTEST=works - # 1 "" works == However, cpp does the same without the dash, but adding a dash _doesn't_ break things. == $ echo TEST|cpp -DTEST=works - # 1 "" works == Regarding unusual places where CPP lives on some systems, this should be (is already?) solved by autoconf. IIRC, ghc relies heavily on gcc's/egcs's features on all platforms, so we loose, if there is none, anyway. autoconf will always prefer an installed gcc over any other compiler, and thus also "gcc -E" over anything else. So the only things we have do, are: * in aclocal.m4, set $fptools_cv_gnu_cpp="$CPP -" and put this into hscpp's $RAWCPP * make mkdependHS use hscpp * remove $RAWCPP from perl scripts, that don't make use of it BTW: I tried Solaris and Linux platforms only, maybe the *BSD, OSF, and Windows folks should do the above tests, too... Cheers, Michael -- standard construction, def: "sort of a mathematical equivalent of 'hey you'" -- Phil Wadler, "Monads"
RE: Preprocessor question
Simon Marlow writes: > > We also like to get as clean a cpp as possible - if you go through gcc -E > you get a whole bunch of symbols defined, The -undef option gets rid of most of those. > and cpp gets passed the -lang-c flag (whatever that means, but it > looks pretty scary). The other possibilities are -lang-c++, -lang-objc, etc. It's to do with things like comment syntax and Objective C's #import directive. It's not as scary as it looks, I think :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998
RE: Preprocessor question
> Simon Marlow <[EMAIL PROTECTED]> wrote: > > > > - mkdependHS and friends need a cpp that accepts input on > > stdin, and files that don't end in ".c". That rules out > > 'gcc -E'. > > Use `gcc -E -` then. Good point :-) We also like to get as clean a cpp as possible - if you go through gcc -E you get a whole bunch of symbols defined, and cpp gets passed the -lang-c flag (whatever that means, but it looks pretty scary). Cheers, Simon
Re: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote: > > - mkdependHS and friends need a cpp that accepts input on > stdin, and files that don't end in ".c". That rules out > 'gcc -E'. Use `gcc -E -` then. Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998
RE: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote, > > > It isn't strictly speaking hardcoded, it's set up when you > > configure a > > > binary distribution. So if you move gcc or install a new > > version, you need > > > to re-install ghc. > > > > I understand the technical issues, but the problem is that > > installing/compiling GHC from source is a *pain* (and > > requires you to have a machine with a lot of memory and a > > fast CPU or a spare machine, which you can afford doing > > nothing else for quite a while). So, IMHO, binary > > distributions are *very important* for GHC. I am sure that > > it is clear that a binary distribution with strict > > dependencies on locations of other tools is far from ideal. > > I think you misunderstood - a standard GHC binary distribution is > independent of the location of cpp on the target machine. It is discovered > when you unpack the distribution and type './configure'. So, all that's > needed is to re-install the binary distribution. Sorry, I indeed misunderstood. (It is too long since I installed a GHC .tar.gz binary distribution.) > This probably isn't the case for RPM's, but as you noted in your message > it's up to the package builder to arrange for the location of cpp and other > tools to be configured at install time. Correct me, if I am wrong again, but if I remember correctly, GHC's .tar.gz binary distributions can be configured either in-situ in one subtree or be made to install into some other place. Unfortunately, both is unsuitable for an RPM (or, as far as I know, for a Debian package). It is a Bad Thing to move files in a RPM post-install script as one of the nice features of RPM is that it keeps track of all the install files and allows to remove complete packages with only a few keystrokes (or mouse clicks). On the other hand, it is necessary that the files stored in the RPM are distributed to /usr/bin, /usr/lib, /usr/doc etc if we want to follow the Linux installation guidelines - which we definitely want (so the standard in-situ installation won't do either). In other words, a Good RPM is snapshot of a selected set of files scattered over the /usr subtree. The post-install script should just patch some configuration file. Thus, > > [...] it would be nice if the path > > (and any other similar dependencies) where located in a > > dedicated file where they are easy to find and patch. One possibility would be to have a `ghc-cpp' script, which is a one liner and just `exec's cpp. We could either patch this script or have different versions `ghc-cpp-', which are linked to `ghc-cpp'. What do you think? Cheers, Manuel
RE: Preprocessor question
> > It isn't strictly speaking hardcoded, it's set up when you > configure a > > binary distribution. So if you move gcc or install a new > version, you need > > to re-install ghc. > > I understand the technical issues, but the problem is that > installing/compiling GHC from source is a *pain* (and > requires you to have a machine with a lot of memory and a > fast CPU or a spare machine, which you can afford doing > nothing else for quite a while). So, IMHO, binary > distributions are *very important* for GHC. I am sure that > it is clear that a binary distribution with strict > dependencies on locations of other tools is far from ideal. I think you misunderstood - a standard GHC binary distribution is independent of the location of cpp on the target machine. It is discovered when you unpack the distribution and type './configure'. So, all that's needed is to re-install the binary distribution. This probably isn't the case for RPM's, but as you noted in your message it's up to the package builder to arrange for the location of cpp and other tools to be configured at install time. > A (somewhat unsatisfactory) solution for package > manager-based distributions (like .rpm or .deb) would be to > use a post-install script that searches for cpp and patches > the path. To make this easier, it would be nice if the path > (and any other similar dependencies) where located in a > dedicated file where they are easy to find and patch. > > > I suppose we can put in a configure test for known locations of cpp > > (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in > preference to > > anything else if it works. > > Do you mean `./configure' at build time? Or a post-install > script (in the sense of my above comment). Both. Cheers, Simon
RE: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote, > > Please, can somebody explain, why the preprocessor is > > hardcoded in the GHC > > perl scripts? IIRC ghc (the perlscript itself) doesn't even reference > > $RAWCPP. mkdependHS and hscpp do, but why an absolute path > > and this obscure > > "-iprefix" parameter? Again, "-iwithprefix" is never used... > > > > Would it break things, if there is '$RAWCPP = "cpp > > -traditional"' only? > > It isn't strictly speaking hardcoded, it's set up when you configure a > binary distribution. So if you move gcc or install a new version, you need > to re-install ghc. I understand the technical issues, but the problem is that installing/compiling GHC from source is a *pain* (and requires you to have a machine with a lot of memory and a fast CPU or a spare machine, which you can afford doing nothing else for quite a while). So, IMHO, binary distributions are *very important* for GHC. I am sure that it is clear that a binary distribution with strict dependencies on locations of other tools is far from ideal. A (somewhat unsatisfactory) solution for package manager-based distributions (like .rpm or .deb) would be to use a post-install script that searches for cpp and patches the path. To make this easier, it would be nice if the path (and any other similar dependencies) where located in a dedicated file where they are easy to find and patch. > I suppose we can put in a configure test for known locations of cpp > (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in preference to > anything else if it works. Do you mean `./configure' at build time? Or a post-install script (in the sense of my above comment). Manuel
Re: Problem with 4.03 FFI on Sparc?
Sven Panne <[EMAIL PROTECTED]> wrote, > Just an aside: Due to some pushing on my part Hugs98 made it onto > the SuSE distribution (6.2), /me praises Sven. How about the Haskell 98 report? I made it into an RPM: ftp://greyarea.is.tsukuba.ac.jp/pub/jibunmaki/src/haskell-doc-98-1.src.rpm Would be nice to have that on CD also (might actually be a reason to switch distributions :-) I would happily improve the RPM and update it with the latest errata if the SuSE people would consider taking it. > but none of the Glasgow fptools. There are two reasons for this: [...] > So my question is: Is there an Alpha aficionado out there to fill > these holes in GHC? It would be nice if GHC were included in a > mainstream Linux distribution. It might be the first "Microsoft product" on a Linux CD ;-) (Sorry, but I just couldn't resist.) Manuel
Re: Problem with 4.03 FFI on Sparc?
Sven Panne <[EMAIL PROTECTED]> wrote, > [ redirected to ghu ] > > "Frank A. Christoph" wrote: > > I wrote: > > > * A more pressing point is that GHC is tied to x86 machines at > > >moment, see e.g. MBlock.c or Adjustor.c. > > It is? I thought these were only relevant for the FFI. > > OK, I was a little vague: MBlock.c is needed by the RTS in any case > and *guesses* a free region in virtual memory for most architectures. > Most guesses seem to be quite good, though. Adjustor.c is only > necessary for foreign export dynamic, so most programs (if not > written by Manuel or me :-) won't notice the omission, but it is > exactly this kind of tiny differences between platforms SuSE tries > to avoid. Furthermore, IMHO, the lack of a working FFI seriously compromises Haskell's value as a general purpose programming language. So, I can understand SuSE insisting on this point. Manuel PS: An intended implication of this comment is that I believe that the Haskell standard should include a FFI.
