RE: cpphs (was Re: Haskell on Red Hat Enterprise...)
On 17 March 2005 23:03, Andy Moran wrote: Malcolm Wallace wrote: Andy Moran [EMAIL PROTECTED] 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. Here's an example, from 6.2.1's ghc/utils/ghc-pkg/Main.hs: -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail \ \ GHC_PKG_VERSION 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? Yes, I fixed all these in 6.2.2 or thereabouts. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: cpphs (was Re: Haskell on Red Hat Enterprise...)
On 17 March 2005 17:23, Malcolm Wallace wrote: The only real issue currently preventing ghc from adopting cpphs is ideological (GPL licensing). We've no objection to making changes to GHC to make it easy to use in conjuction with cpphs (./configure --with-cpps or whatever), so 3rd-party packagers can provide GHC packages that use cpphs if they wish. However, we won't be adding cpphs to the GHC source tree, or requiring it to be installed to build GHC, or shipping it in the standard distributions. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran [EMAIL PROTECTED] writes:
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?
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.
The only real issue currently preventing ghc from adopting cpphs is
ideological (GPL licensing).
http://haskell.org/cpphs/
Regards,
Malcolm
file cpphs.compat
#!/bin/sh
# A minimal compatibility script to make cpphs accept the same
# arguments as real cpp, wherever possible.
# Set this variable as the path to your installed version of cpphs:
CPPHS=/usr/local/bin/cpphs
processArgs () {
TRADITIONAL=no
STRIP=yes
INFILE=-
OUTFILE=-
while test $1 !=
do
case $1 in
-D)shift; echo -D$1 ;;
-D*) echo $1 ;;
-U)shift; echo -U$1 ;;
-U*) echo $1 ;;
-I)shift; echo -I$1 ;;
-I*) echo $1 ;;
-o)shift; echo -O$1 ;;
-o*) echo -O`echo $1 | cut -c3-` ;;
-std*) ;; # ignore language spec
-x)shift ;; # ignore language spec
-ansi*)TRADITIONAL=no ;;
-traditional*) TRADITIONAL=yes ;;
-include) shift; echo $1 ;;
-P)echo --noline ;;
-C)STRIP=no ;;
-CC) STRIP=no ;;
-A)shift ;; # strip assertions
--help)echo $1 ;;
-version) echo -$1 ;;
--version) echo $1 ;;
-*);; # strip all other flags
*) if [ $INFILE = - ]
then INFILE=$1
else OUTFILE=$1
fi ;;
esac
if test $1 != ; then shift; fi
done
if [ $TRADITIONAL = no ]; then echo --hashes; fi
if [ $STRIP = yes ]; then echo --strip;fi
echo $INFILE
if [ $OUTFILE != - ]; then echo -O$OUTFILE; fi
}
exec $CPPHS `processArgs $@`
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
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
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran wrote: 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? Ahem. ... would using cpphs mean _we_ could do away with ... 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
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
Andy Moran [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cpphs (was Re: Haskell on Red Hat Enterprise...)
Malcolm Wallace wrote: Andy Moran [EMAIL PROTECTED] 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. Here's an example, from 6.2.1's ghc/utils/ghc-pkg/Main.hs: -- hackery to convice cpp to splice GHC_PKG_VERSION into a string version :: String version = tail \ \ GHC_PKG_VERSION 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? In addition, you can paste symbol values into strings using either the ANSI stringification operator (#) or the traditional behaviour of expansion within quotes (SYMBOL). So, cpphs' version of traditional is truer to tradition than gcc's, it seems. gcc -E -traditional -x c doesn't expand within quotes, which is why hacks like the above were introduced. 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 [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
