Tomasz Zielonka wrote:

On Thu, Mar 17, 2005 at 10:02:56AM -0500, Francois Meehan wrote:

...

Hi all,

I need Haskell to be installed on a Red advance server 3. Could not find RPM's for it. Tried compiling for tar file, won't pass the ./configure, giving me "configure: error: GHC is required unless bootstrapping from .hc files." error.

Could someone give me some pointers on how to do this?

I was installing GHC 6.2.2 on RH AS r3 on x86 recently and the generic binary distribution for "Generic Linux with glibc 2.3" worked fine. Just download it from the website, configure, make in-place, and you have a working GHC in 5 minutes. You can use this GHC to compile another, newer versions. There is a generic binary x86/Linux glibc 2.3 version of GHC 6.4 on the website too.

This was my experience on Fedora Core 3 too. If building on RHEL3 or FC3, you will likely need to "./configure --with-gcc=gcc33" (provided you have gcc-compat installed). The latest gcc on these systems is 3.4. With 3.4, changes were made to the -traditional version of the C preprocessor that make it incompatible with the way in which many of the Haskell modules in the GHC source tree reify make/build variables as Haskell strings. Have we converged on a long-term solution for this problem? Is hscpp ready for the job? Cheers, Andy -- Andy Moran Ph. (503) 626 6616, x113 Galois Connections Inc. Fax. (503) 350 0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran@galois.com

Malcolm Wallace wrote:

...

Have we converged on a long-term solution for this problem? Is hscpp ready for the job?

I believe cpphs is in good shape. There has been one bug report, and no new feature requests, in the last 4 months since 0.8 was released, with 235 downloads of that version. Over a slightly longer period, it has been used internally by hmake and nhc98 in preference to cpp, with no visible problems.

With the attached compatibility script, it is largely possible to use cpphs as a drop-in replacement for cpp. (The script just translates the command-line argument format.) e.g. ghc -cpp -pgmP cpphs.compat .... works as expected.

I notice that cpphs understands CPP stringification (if invoked with --hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) have to do with fooling -traditional into turning macro constants into Haskell strings, which can more readily be done with the #-operator. So, would using cpphs mean would could do away with the string gap hack?

The only real issue currently preventing ghc from adopting cpphs is ideological (GPL licensing).

http://haskell.org/cpphs/

What implications does the LGPL have for a GHC binary that was built using cpphs, if the GHC binary were used solely within an organization (i.e. not distributed)? What if cpphs were distributed with such a GHC binary as an executable? A -- Andy Moran Ph. (503) 626 6616, x113 Galois Connections Inc. Fax. (503) 350 0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran@galois.com

Andy Moran writes:

I notice that cpphs understands CPP stringification (if invoked with --hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) have to do with fooling -traditional into turning macro constants into Haskell strings, which can more readily be done with the #-operator. So, would using cpphs mean we could do away with the string gap hack?

Without seeing the examples in question, I can't say for definite, but cpphs /does/ preserve string gaps in source code in all cases. In addition, you can paste symbol values into strings using either the ANSI stringification operator (#) or the traditional behaviour of expansion within quotes ("SYMBOL").

What implications does the LGPL have for a GHC binary that was built using cpphs, if the GHC binary were used solely within an organization (i.e. not distributed)?

Both the GPL and LGPL lay obligations on the user of the code only if they re-distribute it - it has no impact on internal use if there is no re-distribution.

What if cpphs were distributed with such a GHC binary as an executable?

If cpphs is distributed as a stand-alone binary, then you must respect the conditions of the GPL with regard to that program (only), i.e. permit re-distribution, publish modified source code etc. This by itself does not place any further restrictions on any of your own software you distribute with it. In GPL terms, this is "mere aggregation", which is non-infective. Your own GHC-produced binary can have any licence you like. It is only if you were to re-use the code from cpphs as a library linked into your own software, that restrictions would apply to your software. In the case of the LGPL, the end user must be given the right to remove cpphs and replace it with a newer version, which tends to imply that you need to link it dynamically rather than statically. However, I expect very few people would need to incorporate cpphs as a library - the stand-alone executable situation is far more likely. Regards, Malcolm

Andy Moran writes:

-- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail "\ \ GHC_PKG_VERSION"

OK, it turns out that this is pretty tricky to do in cpp, even with full scope of -ansi or -traditional behaviour. In fact, the hack shown is the only way to achieve it (demonstrated below), and the hack fails with cpphs /because/ of the string gap! By contrast, "cpphs --text" makes the original task very straightforward. (The option turns off source-code lexing of the file as Haskell, so that macros can be expanded within quotes.) Here are a variety of ways you might attempt stringification: #define GHC_PKG_VERSION 6.2.2 -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail "\ \ GHC_PKG_VERSION" version2 = "GHC_PKG_VERSION" #define v3 "GHC_PKG_VERSION" version3 = v3 #define stringify(s) #s version4 = stringify(GHC_PKG_VERSION) #define stringify2(s) "s" version5 = stringify2(GHC_PKG_VERSION) And here are the results: cpp -ansi version = tail " \ GHC_PKG_VERSION" version2 = "GHC_PKG_VERSION" version3 = "GHC_PKG_VERSION" version4 = "GHC_PKG_VERSION" version5 = "s" cpp -traditional version = tail "\ \ 6.2.2" version2 = "GHC_PKG_VERSION" version3 = "GHC_PKG_VERSION" version4 = #6.2.2 version5 = "GHC_PKG_VERSION" cpphs version = tail "\ \ GHC_PKG_VERSION" version2 = "GHC_PKG_VERSION" version3 = "GHC_PKG_VERSION" version4 = #6.2.2 version5 = "GHC_PKG_VERSION" cpphs --hashes version = tail "\ \ GHC_PKG_VERSION" version2 = "GHC_PKG_VERSION" version3 = "GHC_PKG_VERSION" version4 = "GHC_PKG_VERSION" version5 = "GHC_PKG_VERSION" cpphs --text version = tail "\ \ 6.2.2" version2 = "6.2.2" version3 = "6.2.2" version4 = #6.2.2 version5 = "6.2.2" cpphs --text --hashes version = tail "\ \ 6.2.2" version2 = "6.2.2" version3 = "6.2.2" version4 = "6.2.2" version5 = "6.2.2"

HEAD uses a Makefile-generated Version.hs instead. Simon M.: are all instances of the above trick replaced by analogues of this much neater mechanism?

I agree that, ultimately, generating the source code directly is better than using cpp-ish stuff.

So, cpphs' version of traditional is truer to tradition than gcc's, it seems.

Well, no not really: cpphs is pretty close to cpp -traditional, and cpphs --hashes is pretty close to cpp -ansi, with the treatment of string gaps causing the only slight differences.

"gcc -E -traditional -x c" doesn't expand within quotes, which is why hacks like the above were introduced.

Whilst there /is/ a visible difference between cpp and cpphs for expansion within quotes, where the quotes are located within the definition of the macro (see version5), it isn't relevant here. Your highlighted problem was to do with expansion of macros inside quotes within the main body of the file. Ordinary cpp has no ability to do this whatsoever - the file is always lexed for strings and comments - whilst cpphs is more flexible. Regards, Malcolm