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 :).

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.

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

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

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:hvriedel@gmail.com] Sent: 23 January 2016 17:14 To: Andrey Mokhov Cc: dluposchainsky@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.

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:ben@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

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:hvriedel@gmail.com] Sent: 23 January 2016 17:14 To: Andrey Mokhov Cc: dluposchainsky@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