RE: [ANNOUNCE] Shaking up GHC

[Andrey Mokhov]

Simon & all,

> Why not just make the 'validate' script invoke the shake build system
> (instead of 'make') when you say 'sh validate --shake'?  That would be
> simple, wouldn't it? So shake builds GHC, and then 'validate' invokes
> 'make test' (or whatever) to run the testsuite.
>   
> Little things like this would significantly increase uptake I think!

We can now run:

shake-build/build.sh validate

This will rebuild stage2 GHC, ghc-pkg and hpc if need be, and will then run GHC 
tests by executing `make fast` in `testsuite/tests` folder 
(https://github.com/snowleopard/shaking-up-ghc#testing). 

There is still a lot of work to add proper support for various useful command 
line settings like `TEST=abc` or `TEST_HC=xyz`.

It would be great if someone could add support for `--shake` command line flag 
to the `validate` script, as Simon suggested. This would be a better solution, 
but I'm not confident enough to edit the validate script myself.

Thanks to Thomas Miedema for his patient guidance on how GHC test suite works.

Cheers,
Andrey

> -Original Message-
> From: Simon Peyton Jones [mailto:simo...@microsoft.com]
> Sent: 26 January 2016 08:55
> To: Andrey Mokhov; Ben Gamari
> Cc: ghc-devs@haskell.org
> Subject: RE: [ANNOUNCE] Shaking up GHC
> 
> |  That's correct. Note though that the two build systems put (some)
> |  build results in the same directories, e.g. inplace/bin/ghc-stage1,
> so
> |  there is some interaction between them. In future it would be
> possible
> |  to decouple them completely (if need be).
> 
> Documenting this side-by-side possibility on the home page would be
> very helpful to up-take.
> 
> |  > How can I do that using Shake to build?  Maybe
> |  >  sh validate --shake --fast --no-clean
> |  > or something?  Just modifying the validate script to make it
> |  >convenient to use shake for the build part would be great.
> |
> |  This may be possible precisely because binaries are where validate
> |  expects them to be. I tried to pull this off, but unsuccessfully so
> |  far (validate starts rebuilding everything from scratch with make).
> I
> |  think the reason is that we changed some naming conventions for
> |  directories (using stageN instead of dist, dist-boot, dist-install),
> |  so validate can't find some utils. I'll let you know if I find a
> |  workaround.
> 
> Why not just make the 'validate' script invoke the shake build system
> (instead of 'make') when you say 'sh validate --shake'?  That would be
> simple, wouldn't it?  So shake builds GHC, and then 'validate' invokes
> 'make test' (or whatever) to run the testsuite.
>   
> Little things like this would significantly increase uptake I think!
> 
> Simon
> 
> 
> 
> |
> |  Ben,
> |
> |  > > But User.hs is a source file, which we shouldn't normally modify
> |  > > lest we accidentally commit it. Could we have a non-source file
> to
> |  > > modify (rather like
> |  > >
> |  https://na01.safelinks.protection.outlook.com/?url=build.mk=01%
> |  > >
> |  7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325
> |  > >
> |  be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1=8L%2b7QWlhbAwUnY
> |  > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on
> build.mk.sample)
> |  > >
> |  > One way around this would be to add User.hs to .gitignore. That
> way
> |  > git will ignore changes to this files when you `git commit -a`.
> You
> |  > can still, however, commit changes to it if you ask git
> explicitly.
> |
> |  Yes, I was thinking about the same idea.
> |
> |  Cheers,
> |  Andrey
> |
> |  -Original Message-----
> |  From: Simon Peyton Jones [mailto:simo...@microsoft.com]
> |  Sent: 25 January 2016 12:14
> |  To: Andrey Mokhov <andrey.mok...@newcastle.ac.uk>; ghc-
> |  d...@haskell.org
> |  Cc: Neil Mitchell <ndmitch...@gmail.com>; Simon Marlow
> |  <marlo...@gmail.com>
> |  Subject: RE: [ANNOUNCE] Shaking up GHC
> |
> |  Very good.
> |
> |  As I understand it, it can work side-by-side with the existing build
> |  system, correct?  That means we don't need to make an either/or
> |  choice, which is very helpful.
> |
> |  Every day I do
> | sh validate --fast --no-clean
> |  How can I do that using Shake to build?  Maybe
> | sh validate --shake --fast --no-clean
> |  or something?  Just modifying the validate script to make it
> |  convenient to use shake for the build part would be great.
> |
> |  You say: The make-based build system uses mk/build.mk to specify
> user
> |  build settings. We use src/Settings/User.hs for the same purpose.
> Feel
> |  free to experiment following the Haddock comme

RE: [ANNOUNCE] Shaking up GHC

[Andrey Mokhov]

Simon,

> Documenting this side-by-side possibility on the home page
> would be very helpful to up-take.

Indeed. I added a note on this at the very top of the README.

> Why not just make the 'validate' script invoke the shake build
> system (instead of 'make') when you say 'sh validate --shake'? 
> That would be simple, wouldn't it?  So shake builds GHC, and
> then 'validate' invokes 'make test' (or whatever) to run the testsuite.

Several quick attempts to reuse the validate script have failed, so I decided 
to start implementing a proper test rule in the new build system. (Note, I 
still rely on the old Python scripts for testing -- rewriting them seems to be 
a major undertaking.) The test rule does work for me on Windows, but the 
functionality is very limited at the moment. You can give it a try by running:

shake-build/build.sh test

This should run (some) tests. It shouldn't take long to make it more useful. I 
added a section on testing to the README: 
https://github.com/snowleopard/shaking-up-ghc#testing.

Cheers,
Andrey

-Original Message-
From: Simon Peyton Jones [mailto:simo...@microsoft.com] 
Sent: 26 January 2016 08:55
To: Andrey Mokhov <andrey.mok...@newcastle.ac.uk>; Ben Gamari 
<b...@smart-cactus.org>
Cc: ghc-devs@haskell.org
Subject: RE: [ANNOUNCE] Shaking up GHC

|  That's correct. Note though that the two build systems put (some)  
| build results in the same directories, e.g. inplace/bin/ghc-stage1, so  
| there is some interaction between them. In future it would be possible  
| to decouple them completely (if need be).

Documenting this side-by-side possibility on the home page would be very 
helpful to up-take.

|  > How can I do that using Shake to build?  Maybe
|  >sh validate --shake --fast --no-clean
|  > or something?  Just modifying the validate script to make it  
| >convenient to use shake for the build part would be great.
|  
|  This may be possible precisely because binaries are where validate  
| expects them to be. I tried to pull this off, but unsuccessfully so  
| far (validate starts rebuilding everything from scratch with make). I  
| think the reason is that we changed some naming conventions for  
| directories (using stageN instead of dist, dist-boot, dist-install),  
| so validate can't find some utils. I'll let you know if I find a  
| workaround.

Why not just make the 'validate' script invoke the shake build system (instead 
of 'make') when you say 'sh validate --shake'?  That would be simple, wouldn't 
it?  So shake builds GHC, and then 'validate' invokes 'make test' (or whatever) 
to run the testsuite.

Little things like this would significantly increase uptake I think!

Simon



|  
|  Ben,
|  
|  > > But User.hs is a source file, which we shouldn't normally modify  
| > > lest we accidentally commit it. Could we have a non-source file to  
| > > modify (rather like  > >  
| https://na01.safelinks.protection.outlook.com/?url=build.mk=01%
|  > >
|  7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325
|  > >
|  be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1=8L%2b7QWlhbAwUnY
|  > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on 
| build.mk.sample)  > >  > One way around this would be to add User.hs 
| to .gitignore. That way  > git will ignore changes to this files when 
| you `git commit -a`. You  > can still, however, commit changes to it 
| if you ask git explicitly.
|  
|  Yes, I was thinking about the same idea.
|  
|  Cheers,
|  Andrey
|  
|  -Original Message-
|  From: Simon Peyton Jones [mailto:simo...@microsoft.com]
|  Sent: 25 January 2016 12:14
|  To: Andrey Mokhov <andrey.mok...@newcastle.ac.uk>; ghc-  
| d...@haskell.org
|  Cc: Neil Mitchell <ndmitch...@gmail.com>; Simon Marlow  
| <marlo...@gmail.com>
|  Subject: RE: [ANNOUNCE] Shaking up GHC
|  
|  Very good.
|  
|  As I understand it, it can work side-by-side with the existing build  
| system, correct?  That means we don't need to make an either/or  
| choice, which is very helpful.
|  
|  Every day I do
|   sh validate --fast --no-clean
|  How can I do that using Shake to build?  Maybe
|   sh validate --shake --fast --no-clean  or something?  Just modifying 
| the validate script to make it  convenient to use shake for the build 
| part would be great.
|  
|  You say: The make-based build system uses mk/build.mk to specify user  
| build settings. We use src/Settings/User.hs for the same purpose. Feel  
| free to experiment following the Haddock comments.
|  
|  But User.hs is a source file, which we shouldn't normally modify lest  
| we accidentally commit it.  Could we have a non-source file to modify  
| (rather like  
| https://na01.safelinks.protection.outlook.com/?url=build.mk=01%7c
|  
| 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47
|  
| 74%7c72f988bf86f141af91ab2d7cd011db47%7c1=8L%2b7QWlhbAwU

Re: [ANNOUNCE] Shaking up GHC

[Simon Marlow]

On 23 January 2016 at 21:17, Andrey Mokhov <andrey.mok...@newcastle.ac.uk>
wrote:

> 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
>

It likely won't be that simple due to versioning issues.  It's entirely
possible that GHC will work only with certain versions of some of these
libraries (and not necessarily the latest ones), so the build may fail at
certain times and under certain conditions for some users.  The configure
script will already have to check for compatible versions, like it does for
alex/happy.  That's the reason we bundle things, it reduces the possibility
for failure.

It's a complicated tradeoff, but if the GHC build system became tightly
coupled to Shake in the way that it is with Cabal, then bundling would
probably be the right thing to do.

Cheers,
Simon


> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [ANNOUNCE] Shaking up GHC

[Simon Peyton Jones]

|  That's correct. Note though that the two build systems put (some)
|  build results in the same directories, e.g. inplace/bin/ghc-stage1, so
|  there is some interaction between them. In future it would be possible
|  to decouple them completely (if need be).

Documenting this side-by-side possibility on the home page would be very 
helpful to up-take.

|  > How can I do that using Shake to build?  Maybe
|  >sh validate --shake --fast --no-clean
|  > or something?  Just modifying the validate script to make it
|  >convenient to use shake for the build part would be great.
|  
|  This may be possible precisely because binaries are where validate
|  expects them to be. I tried to pull this off, but unsuccessfully so
|  far (validate starts rebuilding everything from scratch with make). I
|  think the reason is that we changed some naming conventions for
|  directories (using stageN instead of dist, dist-boot, dist-install),
|  so validate can't find some utils. I'll let you know if I find a
|  workaround. 

Why not just make the 'validate' script invoke the shake build system (instead 
of 'make') when you say 'sh validate --shake'?  That would be simple, wouldn't 
it?  So shake builds GHC, and then 'validate' invokes 'make test' (or whatever) 
to run the testsuite.

Little things like this would significantly increase uptake I think!

Simon



|  
|  Ben,
|  
|  > > But User.hs is a source file, which we shouldn't normally modify
|  > > lest we accidentally commit it. Could we have a non-source file to
|  > > modify (rather like
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=build.mk=01%
|  > >
|  7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325
|  > >
|  be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1=8L%2b7QWlhbAwUnY
|  > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample)
|  > >
|  > One way around this would be to add User.hs to .gitignore. That way
|  > git will ignore changes to this files when you `git commit -a`. You
|  > can still, however, commit changes to it if you ask git explicitly.
|  
|  Yes, I was thinking about the same idea.
|  
|  Cheers,
|  Andrey
|  
|  -Original Message-
|  From: Simon Peyton Jones [mailto:simo...@microsoft.com]
|  Sent: 25 January 2016 12:14
|  To: Andrey Mokhov <andrey.mok...@newcastle.ac.uk>; ghc-
|  d...@haskell.org
|  Cc: Neil Mitchell <ndmitch...@gmail.com>; Simon Marlow
|  <marlo...@gmail.com>
|  Subject: RE: [ANNOUNCE] Shaking up GHC
|  
|  Very good.
|  
|  As I understand it, it can work side-by-side with the existing build
|  system, correct?  That means we don't need to make an either/or
|  choice, which is very helpful.
|  
|  Every day I do
|   sh validate --fast --no-clean
|  How can I do that using Shake to build?  Maybe
|   sh validate --shake --fast --no-clean
|  or something?  Just modifying the validate script to make it
|  convenient to use shake for the build part would be great.
|  
|  You say: The make-based build system uses mk/build.mk to specify user
|  build settings. We use src/Settings/User.hs for the same purpose. Feel
|  free to experiment following the Haddock comments.
|  
|  But User.hs is a source file, which we shouldn't normally modify lest
|  we accidentally commit it.  Could we have a non-source file to modify
|  (rather like
|  https://na01.safelinks.protection.outlook.com/?url=build.mk=01%7c
|  01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47
|  74%7c72f988bf86f141af91ab2d7cd011db47%7c1=8L%2b7QWlhbAwUnYfAfCEw
|  TXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample)
|  
|  Simon
|  
|  |  -Original Message-
|  |  From: Andrey Mokhov [mailto:andrey.mok...@newcastle.ac.uk]
|  |  Sent: 22 January 2016 14:27
|  |  To: ghc-devs@haskell.org
|  |  Cc: Simon Peyton Jones <simo...@microsoft.com>; Neil Mitchell
|  | <ndmitch...@gmail.com>; Simon Marlow <marlo...@gmail.com>
|  |  Subject: [ANNOUNCE] Shaking up GHC
|  |
|  |  Dear GHC developers,
|  |
|  |  I am happy to announce that the Shaking up GHC project has finally
|  | reached the first milestone. The goal of the project is to design a
|  | new GHC build system based on Shake that will eventually replace the
|  | current make-based one. See the project page for more details:
|  |  https://github.com/snowleopard/shaking-up-ghc.
|  |
|  |  There is still a long way until we can match the capabilities of
|  the
|  | current build system. At the moment we only build vanilla way.
|  |  Validation, documentation, build flavours and cross-compilation are
|  | not yet implemented. Known limitations are listed here:
|  |  https://github.com/snowleopard/shaking-up-ghc#current-limitations.
|  |
|  |  The purpose of this announcement is to attract alpha testers and
|  | collect early feedback across multiple platforms and build
|  | configurations. We already have several success

Re: [ANNOUNCE] Shaking up GHC

[Joe Hillenbrand]

>
> cabal install alex happy ansi-terminal mtl shake QuickCheck
>>
>
>
It likely won't be that simple due to versioning issues.  It's entirely
> possible that GHC will work only with certain versions of some of these
> libraries (and not necessarily the latest ones), so the build may fail at
> certain times and under certain conditions for some users.


This is exactly why I added build.stack.sh to shaking-up-ghc, to mitigate
these kinds of issues.
https://github.com/snowleopard/shaking-up-ghc/blob/master/build.stack.sh

Personally, I think the shake build system should default to stack because
it is the best way to get consistent builds.

On Tue, Jan 26, 2016 at 2:33 AM, Simon Marlow <marlo...@gmail.com> wrote:

>
>
> On 23 January 2016 at 21:17, Andrey Mokhov <andrey.mok...@newcastle.ac.uk>
> wrote:
>
>> 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
>>
>
> It likely won't be that simple due to versioning issues.  It's entirely
> possible that GHC will work only with certain versions of some of these
> libraries (and not necessarily the latest ones), so the build may fail at
> certain times and under certain conditions for some users.  The configure
> script will already have to check for compatible versions, like it does for
> alex/happy.  That's the reason we bundle things, it reduces the possibility
> for failure.
>
> It's a complicated tradeoff, but if the GHC build system became tightly
> coupled to Shake in the way that it is with Cabal, then bundling would
> probably be the right thing to do.
>
> Cheers,
> Simon
>
>
>> 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
>>
>
>
> ___
> 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

[Ben Gamari]

Simon Peyton Jones  writes:

> Very good.
>
> As I understand it, it can work side-by-side with the existing build
> system, correct? That means we don't need to make an either/or choice,
> which is very helpful.
>
> Every day I do sh validate --fast --no-clean How can I do that using
>   Shake to build? Maybe sh validate --shake --fast --no-clean or
>   something? Just modifying the validate script to make it convenient
>   to use shake for the build part would be great.
>
> You say: The make-based build system uses mk/build.mk to specify user
> build settings. We use src/Settings/User.hs for the same purpose. Feel
> free to experiment following the Haddock comments.
>
> But User.hs is a source file, which we shouldn't normally modify lest
> we accidentally commit it. Could we have a non-source file to modify
> (rather like build.mk being based on build.mk.sample)
>
One way around this would be to add User.hs to .gitignore. That way git
will ignore changes to this files when you `git commit -a`. You can
still, however, commit changes to it if you ask git explicitly.

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

[Andrey Mokhov]

Simon,

> As I understand it, it can work side-by-side with the existing build
> system, correct?  That means we don't need to make an either/or
> choice, which is very helpful.

That's correct. Note though that the two build systems put (some) build results 
in the same directories, e.g. inplace/bin/ghc-stage1, so there is some 
interaction between them. In future it would be possible to decouple them 
completely (if need be).

> How can I do that using Shake to build?  Maybe
>   sh validate --shake --fast --no-clean
> or something?  Just modifying the validate script to make it
> convenient to use shake for the build part would be great.

This may be possible precisely because binaries are where validate expects them 
to be. I tried to pull this off, but unsuccessfully so far (validate starts 
rebuilding everything from scratch with make). I think the reason is that we 
changed some naming conventions for directories (using stageN instead of dist, 
dist-boot, dist-install), so validate can't find some utils. I'll let you know 
if I find a workaround. Otherwise we'll just have to wait for the proper 
implementation of the "test" target in the new build system. Maybe it's not too 
difficult to implement.

Ben,

> > But User.hs is a source file, which we shouldn't normally modify lest 
> > we accidentally commit it. Could we have a non-source file to modify 
> > (rather like build.mk being based on build.mk.sample)
> >
> One way around this would be to add User.hs to .gitignore. That way git
> will ignore changes to this files when you `git commit -a`. You can still,
> however, commit changes to it if you ask git explicitly.

Yes, I was thinking about the same idea. 

Cheers,
Andrey

-Original Message-
From: Simon Peyton Jones [mailto:simo...@microsoft.com] 
Sent: 25 January 2016 12:14
To: Andrey Mokhov <andrey.mok...@newcastle.ac.uk>; ghc-devs@haskell.org
Cc: Neil Mitchell <ndmitch...@gmail.com>; Simon Marlow <marlo...@gmail.com>
Subject: RE: [ANNOUNCE] Shaking up GHC

Very good.

As I understand it, it can work side-by-side with the existing build system, 
correct?  That means we don't need to make an either/or choice, which is very 
helpful.

Every day I do
sh validate --fast --no-clean
How can I do that using Shake to build?  Maybe
sh validate --shake --fast --no-clean
or something?  Just modifying the validate script to make it convenient to use 
shake for the build part would be great.

You say: The make-based build system uses mk/build.mk to specify user build 
settings. We use src/Settings/User.hs for the same purpose. Feel free to 
experiment following the Haddock comments.

But User.hs is a source file, which we shouldn't normally modify lest we 
accidentally commit it.  Could we have a non-source file to modify (rather like 
build.mk being based on build.mk.sample)

Simon

|  -Original Message-
|  From: Andrey Mokhov [mailto:andrey.mok...@newcastle.ac.uk]
|  Sent: 22 January 2016 14:27
|  To: ghc-devs@haskell.org
|  Cc: Simon Peyton Jones <simo...@microsoft.com>; Neil Mitchell  
| <ndmitch...@gmail.com>; Simon Marlow <marlo...@gmail.com>
|  Subject: [ANNOUNCE] Shaking up GHC
|  
|  Dear GHC developers,
|  
|  I am happy to announce that the Shaking up GHC project has finally  
| reached the first milestone. The goal of the project is to design a  
| new GHC build system based on Shake that will eventually replace the  
| current make-based one. See the project page for more details:
|  https://github.com/snowleopard/shaking-up-ghc.
|  
|  There is still a long way until we can match the capabilities of the  
| current build system. At the moment we only build vanilla way.
|  Validation, documentation, build flavours and cross-compilation are  
| not yet implemented. Known limitations are listed here:
|  https://github.com/snowleopard/shaking-up-ghc#current-limitations.
|  
|  The purpose of this announcement is to attract alpha testers and  
| collect early feedback across multiple platforms and build  
| configurations. We already have several success reports on Linux, OS  
| X, Solaris and Windows. However, things will inevitably break and we  
| hope to catch and fix as many of these cases as possible with your  
| help. The instructions on how to try the new build system can be found
|  here: https://github.com/snowleopard/shaking-up-ghc#your-first-build.
|  
|  We plan to be ready to become a part of the GHC tree around 1 March  
| 2016, and catch up with the make build system around 1 June 2016. The  
| dates are tentative and depend on how much time it takes us to resolve  
| the remaining issues: https://github.com/snowleopard/shaking-up-
|  ghc/milestones.
|  
|  I would like thank everyone who contributed to this project so far:
|  Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the  
| idea and guided me throughout the project; Mo

RE: [ANNOUNCE] Shaking up GHC

[Simon Peyton Jones]

Very good.

As I understand it, it can work side-by-side with the existing build system, 
correct?  That means we don't need to make an either/or choice, which is very 
helpful.

Every day I do
sh validate --fast --no-clean
How can I do that using Shake to build?  Maybe
sh validate --shake --fast --no-clean
or something?  Just modifying the validate script to make it convenient to use 
shake for the build part would be great.

You say: The make-based build system uses mk/build.mk to specify user build 
settings. We use src/Settings/User.hs for the same purpose. Feel free to 
experiment following the Haddock comments.

But User.hs is a source file, which we shouldn't normally modify lest we 
accidentally commit it.  Could we have a non-source file to modify (rather like 
build.mk being based on build.mk.sample)

Simon

|  -Original Message-
|  From: Andrey Mokhov [mailto:andrey.mok...@newcastle.ac.uk]
|  Sent: 22 January 2016 14:27
|  To: ghc-devs@haskell.org
|  Cc: Simon Peyton Jones <simo...@microsoft.com>; Neil Mitchell
|  <ndmitch...@gmail.com>; Simon Marlow <marlo...@gmail.com>
|  Subject: [ANNOUNCE] Shaking up GHC
|  
|  Dear GHC developers,
|  
|  I am happy to announce that the Shaking up GHC project has finally
|  reached the first milestone. The goal of the project is to design a
|  new GHC build system based on Shake that will eventually replace the
|  current make-based one. See the project page for more details:
|  https://github.com/snowleopard/shaking-up-ghc.
|  
|  There is still a long way until we can match the capabilities of the
|  current build system. At the moment we only build vanilla way.
|  Validation, documentation, build flavours and cross-compilation are
|  not yet implemented. Known limitations are listed here:
|  https://github.com/snowleopard/shaking-up-ghc#current-limitations.
|  
|  The purpose of this announcement is to attract alpha testers and
|  collect early feedback across multiple platforms and build
|  configurations. We already have several success reports on Linux, OS
|  X, Solaris and Windows. However, things will inevitably break and we
|  hope to catch and fix as many of these cases as possible with your
|  help. The instructions on how to try the new build system can be found
|  here: https://github.com/snowleopard/shaking-up-ghc#your-first-build.
|  
|  We plan to be ready to become a part of the GHC tree around 1 March
|  2016, and catch up with the make build system around 1 June 2016. The
|  dates are tentative and depend on how much time it takes us to resolve
|  the remaining issues: https://github.com/snowleopard/shaking-up-
|  ghc/milestones.
|  
|  I would like thank everyone who contributed to this project so far:
|  Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the
|  idea and guided me throughout the project; Moritz Angermann, Ben
|  Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell
|  contributed to the codebase. Thank you all!
|  
|  Kind regards,
|  Andrey

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Shaking up GHC

[George Colpitts]

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 <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

[Andrey Mokhov]

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 <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

RE: [ANNOUNCE] Shaking up GHC

[Andrey Mokhov]

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 
<andrey.mok...@newcastle.ac.uk<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 
> <dluposchain...@googlemail.com<mailto:dluposchain...@googlemail.com>>
> To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
> Subject: Re: [ANNOUNCE] Shaking up GHC
> Message-ID: <56a27eb1.1080...@gmail.com<mailto: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<mailto: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

[Herbert Valerio Riedel]

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

[Karel Gardas]

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]

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

[Herbert Valerio Riedel]

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

[Ben Gamari]

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

[Tuncer Ayaz]

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

[Tuncer Ayaz]

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

[Tuncer Ayaz]

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

[Edward Z. Yang]

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

[Andrey Mokhov]

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

[Matthias Kilian]

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

[Ben Gamari]

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

[Andrey Mokhov]

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 <andrey.mok...@newcastle.ac.uk> 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

[Ben Gamari]

Andrey Mokhov  writes:

> Dear GHC developers,
>
> I am happy to announce that the Shaking up GHC project has finally
> reached the first milestone. The goal of the project is to design a
> new GHC build system based on Shake that will eventually replace the
> current make-based one. See the project page for more details:
> https://github.com/snowleopard/shaking-up-ghc.
>
Congratulations, Andrey! I'm looking forward to seeing how this project
progresses.

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