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 [EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
