Malcolm Wallace wrote:
Sven Panne [EMAIL PROTECTED] wrote:
they come with different sets of tools:
GHC: hsc2hs
Hugs: hsc2hs, cpphs
nhc: cpphs
The only reason ghc does not ship by default with cpphs is ideological -
the latter is GPL licensed. Of
On Tuesday 27 March 2007 11:48, Simon Marlow wrote:
We distribute gcc not just for its CPP support, but also because GHC still
supports compilation via C, and because GHC can be used as a front-end to
the C compiler. I'd happily swap a dependency on gcc for one on cpphs, but
that's not an
Sven Panne [EMAIL PROTECTED] wrote:
I am not very radical about licenses, but a lot of distros are, so the
problem still remains: cpphs' LGPL (why the initial L for a
program, BTW?)
The library package is LGPL.
The executable that uses the library is GPL.
is incompatible with Hugs' and
On Tuesday 27 March 2007 17:34, Malcolm Wallace wrote:
The library package is LGPL.
The executable that uses the library is GPL.
Ah, OK...
Really? The FSF makes it quite clear that the advertising-clause-free
BSD licence is compatible with the GPL. They also make it clear that
merely
On Thursday 15 March 2007 21:28, Ian Lynagh wrote:
On Thu, Mar 15, 2007 at 07:46:09PM +0100, Sven Panne wrote:
BTW, the toplevel directory of darcs.haskell.org needs some serious
cleanup,
There are plans[0] to get a community server where anyone can come
along and get a project hosted in
On Thursday 15 March 2007 21:34, Ian Lynagh wrote:
hsc2hs gives different output on different platforms, so anyone building
from source needs it, not just those building from darcs.
I came to the same conclusion this morning while standing under the
shower... :-) So things are quite different
Sven Panne [EMAIL PROTECTED] wrote:
OK, now I remember. :-) Hmmm, that seems to indicate that splitting
off at least cpphs from the Hugs/nhc98 distributions is the right
way. And because of a similar reasoning, hsc2hs should not be
distributed with nhc98.
But the very reason that cpphs and
Sven Panne [EMAIL PROTECTED] wrote:
GHC/Hugs/nhc
should fetch these tools via their darcs-all script and use it for
bootstrapping themselves,
At least nhc98 already does this. :-)
but they should *not* install these tools
along with the compiler/interpreter in question.
Well, perhaps
On Fri, Mar 16, 2007 at 12:18:21PM +0100, Sven Panne wrote:
We *do not* install hsc2hs anymore, and make it a standalone project
distributed separately. Same for cpphs.
The only issue I see is that Cabal calls hsc2hs when necessary, but alex
and happy are already in the that situation.
On Friday 16 March 2007 15:45, Ian Lynagh wrote:
The only issue I see is that Cabal calls hsc2hs when necessary, but alex
and happy are already in the that situation. Unfortunately packages
can't depend on tools, they just fail when asked to build. Perhaps there
should be a cabal Tools: field
On Fri, Mar 16, 2007 at 12:12:49PM +, Malcolm Wallace wrote:
Sven Panne [EMAIL PROTECTED] wrote:
but they should *not* install these tools
along with the compiler/interpreter in question.
However, nhc98 won't mind in the slightest if somebody else installs
cpphs as well, or over
Thu Mar 15 08:28:23 PDT 2007 [EMAIL PROTECTED]
* Use update-alternatives for handling generic tool names
ATTENTION: Packagers should read the following stuff carefully!
GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
one hand this is quite handy, avoiding
Sven Panne [EMAIL PROTECTED] wrote:
Alas, this doesn't work well with the Haskell
implementations yet, because they come with different sets of
tools (in addition to runFOO):
GHC: hsc2hs
Hugs: hsc2hs, cpphs
nhc: cpphs
nhc98 does
On Thursday 15 March 2007 17:43, Malcolm Wallace wrote:
nhc98 does actually ship with hsc2hs, but it currently gets used only
during building. It is not installed, in order to avoid conflict with
the ghc-shipped tool of the same name.
If it's installed as hsc2hs-nhc98, then it's OK. I'll have
Sven Panne [EMAIL PROTECTED] wrote:
they come with different sets of tools:
GHC: hsc2hs
Hugs: hsc2hs, cpphs
nhc: cpphs
The only reason ghc does not ship by default with cpphs is ideological -
the latter is GPL licensed. Of course, 3rd-party packagers
While we are at the topic: Is there a deep reason why the cpphs repo is on
www.cs.york.ac.uk and not on darcs.haskell.org? I would like to add a .spec
file etc. to make it a standalone tool, but I can't commit currently. :-(
BTW, the toplevel directory of darcs.haskell.org needs some serious
On Thu, Mar 15, 2007 at 07:46:09PM +0100, Sven Panne wrote:
BTW, the toplevel directory of darcs.haskell.org needs some serious cleanup,
There are plans[0] to get a community server where anyone can come
along and get a project hosted in darcs. The easiest way to do this
cleanup is probably
On Thu, Mar 15, 2007 at 06:21:11PM +0100, Sven Panne wrote:
IIRC, GHC has a slightly modified hsc2hs copy in its source tree. What were
the reasons for this duplication of
http://darcs.haskell.org:/home/darcs/hsc2hs? Shall we remove the hsc2hs from
GHC's source tree and make hsc2hs a
18 matches
Mail list logo
