Re: [ANNOUNCE] Shaking up GHC
I mean, it would be nice if ghc --make was reimplemented using Shake, but there are a few problems (most notably the use of .shake metadata store) which make it hard to be bug-for-bug compatible with the old make. Edward Excerpts from Ben Gamari's message of 2016-01-23 10:45:50 -0800: > Tuncer Ayaz writes: > > > On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > > > >> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: > >> > >> [...] > >> > >> > My suggestion, and what I'd expect, is to make Shake part of GHC's > >> > included lib, just like process or xhtml. > >> > >> please don't; the only reason we include process and xhtml because > >> we *have* to. The less we *have* to bundle, the better. > > > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > > bundling, while using Shake for ghc --make, then I'm all for it. My > > concern is that it has to be as simple as it's currently to install > > ghc on a random Linux distro, in order for someone to use a Shakefile. > > I want more Shakefile users :). > > I'm not sure I follow. Edward's --make support is a front-end plugin; > as far as I know there has been no discussion of shipping it with > GHC-proper. It merely makes use of the new front-end plugin facility. > Perhaps I'm misunderstanding something here? > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] Shaking up GHC
Ben, > Wouldn't > > git clone git://github.com/snowleopard/shaking-up-ghc shake-build > cabal install shake-build/ > > be sufficient? As I understand, this will not take care of alex and happy? Although if we list them as dependencies in shaking-up-ghc.cabal, that will indeed be sufficient... I think it's a good idea :) Cheers, Andrey > -Original Message- > From: Ben Gamari [mailto:b...@smart-cactus.org] > Sent: 23 January 2016 21:22 > To: Andrey Mokhov; Herbert Valerio Riedel; Tuncer Ayaz > Cc: GHC developers > Subject: RE: [ANNOUNCE] Shaking up GHC > > Andrey Mokhov writes: > > > Herbert, > > > >> I think it's already quite convenient. After all, you're expected to > >> have a minimum GHC bootstrapping environment anyway. So having the > >> tools installed (as already do now, e.g. you need alex, happy, and > >> ghc to be able to work on GHC). > > > > I agree. Roughly, we are talking about going from: > > > > cabal install alex happy > > > > to: > > > > cabal install alex happy ansi-terminal mtl shake QuickCheck > > > Wouldn't > > git clone git://github.com/snowleopard/shaking-up-ghc shake-build > cabal install shake-build/ > > be sufficient? > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
Hi,
On Sat, Jan 23, 2016 at 08:09:32PM +0100, Karel Gardas wrote:
> On 01/23/16 06:21 PM, Tuncer Ayaz wrote:
> >If there's a good way in 8.x (with new Cabal and Shake) to avoid
> >bundling, while using Shake for ghc --make, then I'm all for it. My
> >concern is that it has to be as simple as it's currently to install
> >ghc on a random Linux distro, in order for someone to use a Shakefile.
>
> Not only random Linux distro please! GHC supports a lot of other nice OSes
> and it would be a pity if shake-based build does not support them too.
Thanks, Karel, for pointing that out ;-)
First, I don't know Shake, and I didn't follow this thread too
closely, but let me describe the way packages for OpenBSD are built
and used (as I'm the guy who tries to keep ghc and some tools
implemented in Haskell running on that system). This may help
understanding the requirements at least OpenBSD (but probably other
disstributions) have.
- Users install packages (like ghc, darcs, xmonad or the
haskell-platform, which is a meta-package) with OpenBSDs pkg_add(1).
Those packages are fetched from official OpenBSD mirrors. In
porticular, users are *not* expected to build anything themselves (but
of course they may if they want).
- Oficcial binary packages are built for releases and regularly for
OpenBSD-current ('HEAD') on dedicated build machines run by OpenBSD
people.
- Package builds start *from scratch* with only the OpenBSD base system
installed, and whenever the build of one package depends on another
package, the latter has to be built from scratch first.
- Those builds are done from upstream source distributions (like
ghc-7.10.3b-src.tar.bz2); preexisting binaries from external
sources are frowned upon.
- It is, however, acceptable, that a port maintainer supplies
additional distfiles containing precompiled stuff. For example,
for ghc, i provide trimmed down binary builds of ghc for boostrapping.
Here's a proble, because people have to trust me that i'm not
creating a bootstraper doing evil things.
So, in short, the requirements for a system like OpenBSD supporting
ghc as a binary package are self-contained ghc source distrivutions
(with all files needed to build it from source) and a way to create
a ghc bindist that can be used for building ghc from its source
distribution.
Ciao,
Kili
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] Shaking up GHC
Andrey Mokhov writes: > Herbert, > >> I think it's already quite convenient. After all, you're expected to >> have a minimum GHC bootstrapping environment anyway. So having the >> tools installed (as already do now, e.g. you need alex, happy, and >> ghc to be able to work on GHC). > > I agree. Roughly, we are talking about going from: > > cabal install alex happy > > to: > > cabal install alex happy ansi-terminal mtl shake QuickCheck > Wouldn't git clone git://github.com/snowleopard/shaking-up-ghc shake-build cabal install shake-build/ be sufficient? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] Shaking up GHC
Herbert, > I think it's already quite convenient. After all, you're expected to > have a minimum GHC bootstrapping environment anyway. So having the > tools installed (as already do now, e.g. you need alex, happy, and > ghc to be able to work on GHC). I agree. Roughly, we are talking about going from: cabal install alex happy to: cabal install alex happy ansi-terminal mtl shake QuickCheck This doesn't look too onerous (although one could also consider somehow packaging these dependencies together). And hopefully upcoming cabal features will make this more robust. Tuncer, > My suggestion, and what I'd expect, is to make Shake part of > GHC's included lib, just like process or xhtml. This sounds like a very big decision which is beyond the Shaking up GHC project. (I wouldn't want to shake up GHC too much!) Cheers, Andrey > -Original Message- > From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] > Sent: 23 January 2016 17:14 > To: Andrey Mokhov > Cc: dluposchain...@googlemail.com; GHC developers > Subject: Re: [ANNOUNCE] Shaking up GHC > > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: > >> Are there any plans as to how to include it in the GHC tree? Does it > >> ship with all the libraries required to build the build system, will > we > >> have a mini-build system to bootstrap it? If I recall correctly, we > rely > >> on Cabal sandboxes on Linux/OSX and global Cabal library > >> installations on Windows in order to run it. > > > > The simplest way is to add the 'shake-build' folder to the GHC tree > and > > ask first adopters of the new build system to globally install the > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > > and 'build.bat' scripts should work. > > > > I am open to suggestions on how to make this more convenient and > > robust. I've never used anything more advanced than a global cabal > > installation, so I'd appreciate input from more experienced users. > > I think it's already quite convenient. After all, you're expected to > have a minimum GHC bootstrapping environment anyway. So having the > tools > installed (as already do now, e.g. you need alex, happy, and ghc to be > able to work on GHC). > > And the new cabal nix-store feature to show-case as tech-preview > together with GHC 8.0 makes this even more robust by avoiding pkg-db > breakages due to reinstalls, which would be the main reason not to > rely on "global installed dependency". > > The shake-build.sh script simply needs to invoke `cabal new-build` to > generate the ghc shake build-tool executable. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 23 January 2016 at 19:45, Ben Gamari wrote: > I'm not sure I follow. Edward's --make support is a front-end > plugin; as far as I know there has been no discussion of shipping it > with GHC-proper. It merely makes use of the new front-end plugin > facility. Perhaps I'm misunderstanding something here? You likely aren't, and I'm probably under-informed. Viewing 'ghc --make' as a core feature of ghc-the-executable, I've assumed Shake (the lib) to be a build-time+run-time requirement. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 23 January 2016 at 20:09, Karel Gardas wrote: > On 01/23/16 06:21 PM, Tuncer Ayaz wrote: > > > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > > bundling, while using Shake for ghc --make, then I'm all for it. > > My concern is that it has to be as simple as it's currently to > > install ghc on a random Linux distro, in order for someone to use > > a Shakefile. > > > Not only random Linux distro please! GHC supports a lot of other > nice OSes and it would be a pity if shake-based build does not > support them too. Where available via pkgng or pkgsrc, it's also a quick install away. I've mentioned Linux+BSD (and left out Illumos), but subsequently forgot to mention BSDs, etc. here. Sorry about that. Better wording: "as simple as 'pkgmgr install ghc'". ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 01/23/16 06:21 PM, Tuncer Ayaz wrote: If there's a good way in 8.x (with new Cabal and Shake) to avoid bundling, while using Shake for ghc --make, then I'm all for it. My concern is that it has to be as simple as it's currently to install ghc on a random Linux distro, in order for someone to use a Shakefile. Not only random Linux distro please! GHC supports a lot of other nice OSes and it would be a pity if shake-based build does not support them too. Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
Tuncer Ayaz writes: > On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > >> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: >> >> [...] >> >> > My suggestion, and what I'd expect, is to make Shake part of GHC's >> > included lib, just like process or xhtml. >> >> please don't; the only reason we include process and xhtml because >> we *have* to. The less we *have* to bundle, the better. > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > bundling, while using Shake for ghc --make, then I'm all for it. My > concern is that it has to be as simple as it's currently to install > ghc on a random Linux distro, in order for someone to use a Shakefile. > I want more Shakefile users :). I'm not sure I follow. Edward's --make support is a front-end plugin; as far as I know there has been no discussion of shipping it with GHC-proper. It merely makes use of the new front-end plugin facility. Perhaps I'm misunderstanding something here? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: > > [...] > > > My suggestion, and what I'd expect, is to make Shake part of GHC's > > included lib, just like process or xhtml. > > please don't; the only reason we include process and xhtml because > we *have* to. The less we *have* to bundle, the better. If there's a good way in 8.x (with new Cabal and Shake) to avoid bundling, while using Shake for ghc --make, then I'm all for it. My concern is that it has to be as simple as it's currently to install ghc on a random Linux distro, in order for someone to use a Shakefile. I want more Shakefile users :). ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: [...] > My suggestion, and what I'd expect, is to make Shake part of GHC's > included lib, just like process or xhtml. please don't; the only reason we include process and xhtml because we *have* to. The less we *have* to bundle, the better. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: >> Are there any plans as to how to include it in the GHC tree? Does it >> ship with all the libraries required to build the build system, will we >> have a mini-build system to bootstrap it? If I recall correctly, we rely >> on Cabal sandboxes on Linux/OSX and global Cabal library >> installations on Windows in order to run it. > > The simplest way is to add the 'shake-build' folder to the GHC tree and > ask first adopters of the new build system to globally install the > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > and 'build.bat' scripts should work. > > I am open to suggestions on how to make this more convenient and > robust. I've never used anything more advanced than a global cabal > installation, so I'd appreciate input from more experienced users. I think it's already quite convenient. After all, you're expected to have a minimum GHC bootstrapping environment anyway. So having the tools installed (as already do now, e.g. you need alex, happy, and ghc to be able to work on GHC). And the new cabal nix-store feature to show-case as tech-preview together with GHC 8.0 makes this even more robust by avoiding pkg-db breakages due to reinstalls, which would be the main reason not to rely on "global installed dependency". The shake-build.sh script simply needs to invoke `cabal new-build` to generate the ghc shake build-tool executable. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
On 23 January 2016 at 14:05, Andrey Mokhov wrote: > The simplest way is to add the 'shake-build' folder to the GHC tree > and ask first adopters of the new build system to globally install > the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then > 'build.sh' and 'build.bat' scripts should work. > > I am open to suggestions on how to make this more convenient and > robust. I've never used anything more advanced than a global cabal > installation, so I'd appreciate input from more experienced users. > > Could you create a ticket on github suggesting possible > approaches? I'm afraid our discussion may get lost in ghc-devs > mailing list. My suggestion, and what I'd expect, is to make Shake part of GHC's included lib, just like process or xhtml. Neil said this can be a maintenance burden, and I'm aware of that argument, but the bundled libs ghc depends on are not maintained by ghc devs and merely included as known-to-work versions to go with the ghc release as well. Why do I want this? a1) Want to use Shake? Install GHC via OS pkg mgr or prebuilt binary tarball, and be done. This way, telling potential users migrating from Makefile(s) to Shake is as easy as "Install ghc-8.0". Anyone who needs a different Shake version can, as it's done right now with cabal(-install), install Cabal+cabal-install as a 2nd dependency. So, anybody that that wants to use Shake instead of make, can just install ghc itself. That's a very minimal set of requirements and steps, compared to installing Shake after first getting ghc. a2) Like what Xmonad has done for custom window management, Shake can be that for build scripts that are written in one language, compared to Ninja, where it's meant to be generated from something else. Requiring just ghc and nothing else, is easier to sell, given how easy it has been dependency-wise (breakage, etc.) to install ghc on various Linux or BSD distros I've tried it on. a3) As an extension of (a2), it's preferable to write build scripts in Haskell than Guile Scheme, and anything we can do to make that easier is a good thing. We don't want to move m4+(auto)make+sh to Scheme, where it's arguably easier to publish broken scripts due to the dynamic nature them. Why do I think it's not a big deal to do it this way? b1) Seeing how Shake is needed to build ghc itself, Edward's working on using it in ghc --make, and both cabal and stack devs are looking into reusing Shake, it makes a whole lot of sense to not make it an extra dependency. b2) The way I see it, relying on Alex and Happy is, for instance, different, as those are usable as plain executable without a Haskell library. So, by keeping Shake bundled like xhtml or process, we'd not add external dependencies that need ghc and maybe cabal/stack to be built. b3) Just like everyone is free to use a newer xhtml, regardless of what's bundled with a ghc release, nothing prevents you from installing a newer Shake than what's in the ghc release. Thus, I don't think we'd have to make it ghc-private. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] Shaking up GHC
Hi George,
I think you are hitting this bug: https://ghc.haskell.org/trac/ghc/ticket/11379.
Note, you don't have to use GHC HEAD as a bootstrapping compiler. I'm
bootstrapping with GHC 7.10.1, for example.
Cheers,
Andrey
From: George Colpitts [mailto:george.colpi...@gmail.com]
Sent: 23 January 2016 13:36
To: Andrey Mokhov
Cc: dluposchain...@googlemail.com; GHC developers
Subject: Re: [ANNOUNCE] Shaking up GHC
with ghc 8.0.0.20160111, cabal install shake fails with
[43 of 47] Compiling Development.Shake.Args ( src/Development/Shake/Args.hs,
dist/build/Development/Shake/Args.o )
src/Development/Shake/Args.hs:1:1: error:
solveWanteds: too many iterations (limit = 4)
Unsolved: WC {wc_simple =
[D] _ :: Eq a (CDictCan)
[D] _ :: Ord a (CDictCan)
[D] _ :: Read a (CDictCan)
[D] _ :: Show a (CDictCan)
[W] hole{a4gTO} :: a ~ a (CNonCanonical)
[D] _ :: Eq a (CDictCan)}
New superclasses found
Set limit with -fconstraint-solver-iterations=n; n=0 for no limit
Is this a known problem?
Thanks
On Sat, Jan 23, 2016 at 9:05 AM, Andrey Mokhov
mailto:andrey.mok...@newcastle.ac.uk>> wrote:
Thanks David!
> Are there any plans as to how to include it in the GHC tree? Does it
> ship with all the libraries required to build the build system, will we
> have a mini-build system to bootstrap it? If I recall correctly, we rely
> on Cabal sandboxes on Linux/OSX and global Cabal library
> installations on Windows in order to run it.
The simplest way is to add the 'shake-build' folder to the GHC tree and
ask first adopters of the new build system to globally install the
dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh'
and 'build.bat' scripts should work.
I am open to suggestions on how to make this more convenient and
robust. I've never used anything more advanced than a global cabal
installation, so I'd appreciate input from more experienced users.
Could you create a ticket on github suggesting possible approaches?
I'm afraid our discussion may get lost in ghc-devs mailing list.
Many thanks!
Andrey
> From: David Luposchainsky
> mailto:dluposchain...@googlemail.com>>
> To: ghc-devs@haskell.org
> Subject: Re: [ANNOUNCE] Shaking up GHC
> Message-ID: <56a27eb1.1080...@gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Great work Andrey!
>
> I'm actually (pleasantly) surprised this is becoming part of the GHC
> tree so soon
> .
>
> Are there any plans as to how to include it in the GHC tree? Does it
> ship with
> all the libraries required to build the build system, will we have a
> mini-build
> system to bootstrap it? If I recall correctly, we rely on Cabal
> sandboxes on
> Linux/OSX and global Cabal library installations on Windows in order to
> run it.
>
> Greetings,
> David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] Shaking up GHC
with ghc 8.0.0.20160111, cabal install shake fails with
[43 of 47] Compiling Development.Shake.Args (
src/Development/Shake/Args.hs, dist/build/Development/Shake/Args.o )
src/Development/Shake/Args.hs:1:1: error:
solveWanteds: too many iterations (limit = 4)
Unsolved: WC {wc_simple =
[D] _ :: Eq a (CDictCan)
[D] _ :: Ord a (CDictCan)
[D] _ :: Read a (CDictCan)
[D] _ :: Show a (CDictCan)
[W] hole{a4gTO} :: a ~ a (CNonCanonical)
[D] _ :: Eq a (CDictCan)}
New superclasses found
Set limit with -fconstraint-solver-iterations=n; n=0 for no limit
Is this a known problem?
Thanks
On Sat, Jan 23, 2016 at 9:05 AM, Andrey Mokhov <
andrey.mok...@newcastle.ac.uk> wrote:
> Thanks David!
>
>
>
> > Are there any plans as to how to include it in the GHC tree? Does it
>
> > ship with all the libraries required to build the build system, will we
>
> > have a mini-build system to bootstrap it? If I recall correctly, we rely
>
> > on Cabal sandboxes on Linux/OSX and global Cabal library
>
> > installations on Windows in order to run it.
>
>
>
> The simplest way is to add the 'shake-build' folder to the GHC tree and
>
> ask first adopters of the new build system to globally install the
>
> dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh'
>
> and 'build.bat' scripts should work.
>
>
>
> I am open to suggestions on how to make this more convenient and
>
> robust. I've never used anything more advanced than a global cabal
>
> installation, so I'd appreciate input from more experienced users.
>
>
>
> Could you create a ticket on github suggesting possible approaches?
>
> I'm afraid our discussion may get lost in ghc-devs mailing list.
>
>
>
> Many thanks!
>
> Andrey
>
>
>
> > From: David Luposchainsky
>
> > To: ghc-devs@haskell.org
>
> > Subject: Re: [ANNOUNCE] Shaking up GHC
>
> > Message-ID: <56a27eb1.1080...@gmail.com>
>
> > Content-Type: text/plain; charset=windows-1252
>
> >
>
> > Great work Andrey!
>
> >
>
> > I'm actually (pleasantly) surprised this is becoming part of the GHC
>
> > tree so soon
>
> > .
>
> >
>
> > Are there any plans as to how to include it in the GHC tree? Does it
>
> > ship with
>
> > all the libraries required to build the build system, will we have a
>
> > mini-build
>
> > system to bootstrap it? If I recall correctly, we rely on Cabal
>
> > sandboxes on
>
> > Linux/OSX and global Cabal library installations on Windows in order to
>
> > run it.
>
> >
>
> > Greetings,
>
> > David
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] Shaking up GHC
Thanks David! > Are there any plans as to how to include it in the GHC tree? Does it > ship with all the libraries required to build the build system, will we > have a mini-build system to bootstrap it? If I recall correctly, we rely > on Cabal sandboxes on Linux/OSX and global Cabal library > installations on Windows in order to run it. The simplest way is to add the 'shake-build' folder to the GHC tree and ask first adopters of the new build system to globally install the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' and 'build.bat' scripts should work. I am open to suggestions on how to make this more convenient and robust. I've never used anything more advanced than a global cabal installation, so I'd appreciate input from more experienced users. Could you create a ticket on github suggesting possible approaches? I'm afraid our discussion may get lost in ghc-devs mailing list. Many thanks! Andrey > From: David Luposchainsky > To: ghc-devs@haskell.org > Subject: Re: [ANNOUNCE] Shaking up GHC > Message-ID: <56a27eb1.1080...@gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Great work Andrey! > > I'm actually (pleasantly) surprised this is becoming part of the GHC > tree so soon > . > > Are there any plans as to how to include it in the GHC tree? Does it > ship with > all the libraries required to build the build system, will we have a > mini-build > system to bootstrap it? If I recall correctly, we rely on Cabal > sandboxes on > Linux/OSX and global Cabal library installations on Windows in order to > run it. > > Greetings, > David ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Options -Wmissed-specialisations, -Wall-missed-specialisations and -Werror
Andrés Sicard-Ramírez writes: > Dear all, > > In GHC 8 RC 1, the `-Wmissed-specialisations` and > `-Wall-missed-specialisations` options generate a warning instead of > an error when using `-Werror`. Is it the expected behaviour? > I would say this can be considered correct. This warning is really intended to let the user know that a specialization hasn't occurred; fixing this may require changes in code which they have little control over (e.g. adding an inline pragma to an upstream library). Regardless, this behavior probably ought to be a bit better documented. I've opened D1829 fixing this. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
