RE: [ANNOUNCE] Shaking up GHC
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&data=01% > | > > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 > | > > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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 ; ghc- > | d...@haskell.org > | Cc: Neil Mitchell ; Simon Marlow > | > | 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 pur
RE: [ANNOUNCE] Shaking up GHC
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 ; 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&data=01% | > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 | > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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 ; ghc- | d...@haskell.org | Cc: Neil Mitchell ; Simon Marlow | | 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&data=01%7c | | 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47 | | 74%7c72f988bf86f141af91ab2d7cd011db47%7
Re: [ANNOUNCE] Shaking up GHC
> > 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 wrote: > > > On 23 January 2016 at 21:17, Andrey Mokhov > 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
On 23 January 2016 at 21:17, Andrey Mokhov 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
| 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&data=01% | > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 | > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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 ; ghc- | d...@haskell.org | Cc: Neil Mitchell ; Simon Marlow | | 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&data=01%7c | 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47 | 74%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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 ; Neil Mitchell | | ; Simon Marlow | | 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. Ho
RE: [ANNOUNCE] Shaking up GHC
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 ; ghc-devs@haskell.org Cc: Neil Mitchell ; Simon Marlow 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 ; Neil Mitchell | ; Simon Marlow | 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! |
RE: [ANNOUNCE] Shaking up GHC
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
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 ; Neil Mitchell | ; Simon Marlow | 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
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<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
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: [ANNOUNCE] Shaking up GHC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWon6xAAoJELrQsaT5WQUs/WUIAL8K6+pQh/hWqJCIDb1SG6+r 2wGkAd9CpihFX10farMUo4irakiRkwqQdw2r82LAHluaXIqiM8cr6k2kKJh/hOEl 2ct475akN3p7KlNlV4b74xSXPK6WmU0gabR7lkQm1FGQQbB1Gl9ztKpaL+x4vygj ZbQS76h6K+xMy+oLBXgC2bHALYb4fK/1u9JDuAFuJeGqhwy6xcdgr0QOMLY8x3P0 JGeiKT0nsJ8359nj28/BPPJz3yjNdHqcMU3F8lCY96N+r8K+gwo8VTLhji/3MIMT 7amh2D8bpfbK7Ckv9B5tD4OsYVRDgy9iRF54sSu1Qce1YhsPFnRoD4b2teV3UHs= =zLQ3 -END 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 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
[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