Re: [ANNOUNCE] You should try Hadrian
Side note: On my Windows my machine, where I use the environment provided by `stack exec --no-ghc-package-path bash`, I have to do `bash -c 'pushd . && . /etc/profile && popd && ./configure --enable-tarballs-autodownload'` or something along those lines for some time now (probably since the boot script has been rewritten to python?). Am Mo., 28. Jan. 2019 um 00:44 Uhr schrieb Phyx : > Hi Andrey > > On Sun, Jan 27, 2019 at 10:49 PM Andrey Mokhov < > andrey.mok...@newcastle.ac.uk> wrote: > >> Hi Tamar, >> >> >> >> Here is the relevant bullet point from the README: >> >> >> >> > On Windows, if you do not want to install MSYS, you can >> >> > use the Stack-based build script (Stack provides a managed >> >> > MSYS environment), as described in these instructions. >> >> > If you don't mind installing MSYS yourself or already have it, >> >> > you can use the Cabal-based build script. >> > > Yes, I was referring to the "My first build" heading which had a call to > build.bat, but it seems my branch was just old and the file was updated 11 > days ago to use cabal instead of stack. > Now the rest of the file also makes sense. Apologies for that, I thought I > had updated > > >> >> This claim is based on my experience. Installing the MSYS environment has >> never worked out smoothly for me. Doing this via Stack was indeed more >> robust (especially, when struggling with building GHC on Windows CI!). Has >> this been different in your experience? >> >> >> > > Yes, stack does nothing special than just un-tar the binary distribution > of msys2. The problem is that this binary distribution is not kept up to > date unless things break. By that point they may have gotten so out of date > that the distribution simply can't even be upgraded. e.g. A while ago they > used a distribution that's so old it couldn't deal with pacman's > invalidating old certificates, which means you couldn't use it to update > ca-certificates. > > It also can't handle when msys upstream changes core dependencies. One > such update is a change in march that introduced a cyclic dependency > between catgets libcatgets and some packages. Or when they change the > package layout as they did removing the old shell scripts and making > Mingw32.exe and Mingw64.exe. I can name many more. The fact is the msys2 > installers are set up to work around these updates, or you must work around > them when initializing the environment to fix these. > > And I see no evidence based on past issues that stack actually keeps their > msys2 installs up to date. So I don't want to go into the business of > managing stack msys2 issues for ghc builds. > > > I'm just confused when it was decided to switch the defaults, >> >> > and why, without any consultation. >> >> >> >> I’m not sure what you mean. Could you clarify? The file `doc/windows.md` >> is 3 years old and hasn’t changed much since creation. The default build >> script `build.bat` currently uses Cabal: >> >> >> >> ``` >> >> rem By default on Windows we build Hadrian using Cabal >> >> hadrian/build.cabal.bat %* >> >> ``` >> > > Yes.. I'm pretty sure when I looked at it before today it was pointing to > build.stack.bat, but that seems to be a two week old tree. So my fault > there. > > Sorry, should have checked on gitlab! > > Regards, > Tamar > > >> >> >> P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when >> moving to GitLab, and created this MR to fix this: >> >> >> >> https://gitlab.haskell.org/ghc/ghc/merge_requests/239 >> >> >> >> Please jump into the comments there if you’d like me to fix/clarify >> anything. >> >> >> >> Thanks for reaching out! >> >> >> >> Cheers, >> >> Andrey >> >> >> >> *From:* Phyx [mailto:loneti...@gmail.com] >> *Sent:* 27 January 2019 21:11 >> *To:* Andrey Mokhov ; Ben Gamari < >> b...@well-typed.com> >> *Cc:* GHC developers >> *Subject:* Re: [ANNOUNCE] You should try Hadrian >> >> >> >> Hi Andrey, >> >> >> >> I'm looking at >> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and >> https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md >> >> wondering why the default instructions for Windows are using stack, this >> isn't currently the case. >> >> >> >> In order for ./boot and configure to work already you need to be in an >> msys2 environment. So having stack install its own, un-updated msys2 is not >> a workflow I would recommend. >> >> >> >> There's a dubious claim there that using stack is "more robust", what is >> this claim based on? >> >> I'm just confused when it was decided to switch the defaults, and why, >> without any consultation. >> >> >> >> Regards, >> >> Tamar >> > ___ > 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] You should try Hadrian
Hi Andrey On Sun, Jan 27, 2019 at 10:49 PM Andrey Mokhov < andrey.mok...@newcastle.ac.uk> wrote: > Hi Tamar, > > > > Here is the relevant bullet point from the README: > > > > > On Windows, if you do not want to install MSYS, you can > > > use the Stack-based build script (Stack provides a managed > > > MSYS environment), as described in these instructions. > > > If you don't mind installing MSYS yourself or already have it, > > > you can use the Cabal-based build script. > Yes, I was referring to the "My first build" heading which had a call to build.bat, but it seems my branch was just old and the file was updated 11 days ago to use cabal instead of stack. Now the rest of the file also makes sense. Apologies for that, I thought I had updated > > This claim is based on my experience. Installing the MSYS environment has > never worked out smoothly for me. Doing this via Stack was indeed more > robust (especially, when struggling with building GHC on Windows CI!). Has > this been different in your experience? > > > Yes, stack does nothing special than just un-tar the binary distribution of msys2. The problem is that this binary distribution is not kept up to date unless things break. By that point they may have gotten so out of date that the distribution simply can't even be upgraded. e.g. A while ago they used a distribution that's so old it couldn't deal with pacman's invalidating old certificates, which means you couldn't use it to update ca-certificates. It also can't handle when msys upstream changes core dependencies. One such update is a change in march that introduced a cyclic dependency between catgets libcatgets and some packages. Or when they change the package layout as they did removing the old shell scripts and making Mingw32.exe and Mingw64.exe. I can name many more. The fact is the msys2 installers are set up to work around these updates, or you must work around them when initializing the environment to fix these. And I see no evidence based on past issues that stack actually keeps their msys2 installs up to date. So I don't want to go into the business of managing stack msys2 issues for ghc builds. > I'm just confused when it was decided to switch the defaults, > > > and why, without any consultation. > > > > I’m not sure what you mean. Could you clarify? The file `doc/windows.md` > is 3 years old and hasn’t changed much since creation. The default build > script `build.bat` currently uses Cabal: > > > > ``` > > rem By default on Windows we build Hadrian using Cabal > > hadrian/build.cabal.bat %* > > ``` > Yes.. I'm pretty sure when I looked at it before today it was pointing to build.stack.bat, but that seems to be a two week old tree. So my fault there. Sorry, should have checked on gitlab! Regards, Tamar > > > P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when > moving to GitLab, and created this MR to fix this: > > > > https://gitlab.haskell.org/ghc/ghc/merge_requests/239 > > > > Please jump into the comments there if you’d like me to fix/clarify > anything. > > > > Thanks for reaching out! > > > > Cheers, > > Andrey > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 27 January 2019 21:11 > *To:* Andrey Mokhov ; Ben Gamari < > b...@well-typed.com> > *Cc:* GHC developers > *Subject:* Re: [ANNOUNCE] You should try Hadrian > > > > Hi Andrey, > > > > I'm looking at > https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and > https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md > > wondering why the default instructions for Windows are using stack, this > isn't currently the case. > > > > In order for ./boot and configure to work already you need to be in an > msys2 environment. So having stack install its own, un-updated msys2 is not > a workflow I would recommend. > > > > There's a dubious claim there that using stack is "more robust", what is > this claim based on? > > I'm just confused when it was decided to switch the defaults, and why, > without any consultation. > > > > Regards, > > Tamar > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: [ANNOUNCE] You should try Hadrian
Hi Tamar, Here is the relevant bullet point from the README: > On Windows, if you do not want to install MSYS, you can > use the Stack-based build script (Stack provides a managed > MSYS environment), as described in these instructions. > If you don't mind installing MSYS yourself or already have it, > you can use the Cabal-based build script. As you can see, `doc/windows.md` is recommended for people who “do not want to install MSYS”. Perhaps, the wording is not clear enough – please feel free to suggest improvements. > In order for ./boot and configure to work already you need to > be in an msys2 environment. Yes, and Stack provides it. This means, if you follow instructions in this file, you don’t need to install MSYS yourself. > There's a dubious claim there that using stack is > "more robust", what is this claim based on? This claim is based on my experience. Installing the MSYS environment has never worked out smoothly for me. Doing this via Stack was indeed more robust (especially, when struggling with building GHC on Windows CI!). Has this been different in your experience? > I'm just confused when it was decided to switch the defaults, > and why, without any consultation. I’m not sure what you mean. Could you clarify? The file `doc/windows.md` is 3 years old and hasn’t changed much since creation. The default build script `build.bat` currently uses Cabal: ``` rem By default on Windows we build Hadrian using Cabal hadrian/build.cabal.bat %* ``` P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when moving to GitLab, and created this MR to fix this: https://gitlab.haskell.org/ghc/ghc/merge_requests/239 Please jump into the comments there if you’d like me to fix/clarify anything. Thanks for reaching out! Cheers, Andrey From: Phyx [mailto:loneti...@gmail.com] Sent: 27 January 2019 21:11 To: Andrey Mokhov ; Ben Gamari Cc: GHC developers Subject: Re: [ANNOUNCE] You should try Hadrian Hi Andrey, I'm looking at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md wondering why the default instructions for Windows are using stack, this isn't currently the case. In order for ./boot and configure to work already you need to be in an msys2 environment. So having stack install its own, un-updated msys2 is not a workflow I would recommend. There's a dubious claim there that using stack is "more robust", what is this claim based on? I'm just confused when it was decided to switch the defaults, and why, without any consultation. Regards, Tamar ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] You should try Hadrian
Hi Andrey, I'm looking at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md wondering why the default instructions for Windows are using stack, this isn't currently the case. In order for ./boot and configure to work already you need to be in an msys2 environment. So having stack install its own, un-updated msys2 is not a workflow I would recommend. There's a dubious claim there that using stack is "more robust", what is this claim based on? I'm just confused when it was decided to switch the defaults, and why, without any consultation. Regards, Tamar On Fri, Jan 25, 2019 at 2:27 AM Andrey Mokhov wrote: > Dear GHC developers, > > > > Summary: You should try to use Hadrian as the GHC build system, because it > will (hopefully!) become the default around GHC 8.8. > > > > What is Hadrian and how can I try it? > > = > > > > Hadrian is a new build system for GHC written in Haskell. It lives in the > directory “hadrian” in the GHC tree, and we have been actively developing > it in the past year to reach feature and correctness parity with the > existing Make-based build system. While we haven't quite reached this goal > (more on this below), Hadrian is already working well and we run Hadrian > jobs alongside the Make ones in our CI pipelines since the recent move to > GitLab. > > > > At this point, we would like to encourage everyone to try using Hadrian > for their usual GHC development tasks. Hadrian's documentation resides in > GHC's source tree, and below are the documents you will be most interested > in: > > > > ·https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md: > The root of Hadrian's documentation. It explains the basics and points to > more specific documents where appropriate. > > > > · > https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md: A > cheatsheet-style document for GHC developers used to the Make build system > (that is, most/all of you), showing equivalent Make/Hadrian commands for > many tasks. > > > > · > https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md: > A description of the “user settings” mechanism in Hadrian, which is where > you can customise the build flavour, choose the packages to build, add > file/package/platform-specific command line flags, etc. > > > > · > https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md: > A description of the “test” rule and all the options it supports. > > > > The documentation can surely be improved, so please do not hesitate to > send us feedback and suggestions here, or even better on Trac: make sure > you choose the component "Build System (Hadrian)" when creating a new > ticket. > > > > You need Hadrian > > > > > > Hadrian is new, requires time to learn, and still has rough edges, but it > has been developed to make your lives better. Here are a few advantages of > Hadrian over the Make-based build system: > > > > 1) Hadrian is more reliable. > > > > Hadrian can capture build dependencies more accurately, which means you > rarely (if ever) need to do a clean rebuild. > > > > 2) Hadrian is faster. > > > > Hadrian is faster for two reasons: (i) more accurate build dependencies, > (ii) tracking of file contents instead of file modification times. Both > allow you to avoid a lot of unnecessary rebuilds. Building Hadrian itself > may take a while but needs to be done only once. > > > > 3) Hadrian is easier to understand and modify. > > > > You no longer need to deal with Make's global namespace of mutable string > variables. Hadrian is written in the language you love; it has modules, > types and pure functions. > > > > > > If you come across a situation where Hadrian is worse than the Make build > system in any of the above aspects, this is a bug and you should report it. > > > > Helping Hadrian > > === > > > > The best way to help is to try Hadrian, and let us know how it goes, what > doesn't work, what's missing for you, what you think should be easier, and > so on. Below is a list of known issues that we are in the process of fixing > or that we will be tackling soon: > > > > ·Stage 2 GHC should be dynamically linked most of the time, but > it never is, currently. See https://ghc.haskell.org/trac/ghc/ticket/15837 > > ·There are about a dozen of failing tests in the GHC testsuite, > some related to #15837. > > ·Binary distributions haven't been thoroughly tested on many > platforms (only some Linux flavours). There will definitely be some issues > here. For example, the binary distribution rule currently fails on Windows: > https://ghc.haskell.org/trac/ghc/ticket/16073. > > ·There is no “validate” rule yet, only “test”, but we have all > the pieces to make this happen and it has a very high priority. > > ·There are issues with building cross compilers: see >
[ANNOUNCE] You should try Hadrian
Dear GHC developers, Summary: You should try to use Hadrian as the GHC build system, because it will (hopefully!) become the default around GHC 8.8. What is Hadrian and how can I try it? = Hadrian is a new build system for GHC written in Haskell. It lives in the directory "hadrian" in the GHC tree, and we have been actively developing it in the past year to reach feature and correctness parity with the existing Make-based build system. While we haven't quite reached this goal (more on this below), Hadrian is already working well and we run Hadrian jobs alongside the Make ones in our CI pipelines since the recent move to GitLab. At this point, we would like to encourage everyone to try using Hadrian for their usual GHC development tasks. Hadrian's documentation resides in GHC's source tree, and below are the documents you will be most interested in: *https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md: The root of Hadrian's documentation. It explains the basics and points to more specific documents where appropriate. *https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md: A cheatsheet-style document for GHC developers used to the Make build system (that is, most/all of you), showing equivalent Make/Hadrian commands for many tasks. * https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md: A description of the "user settings" mechanism in Hadrian, which is where you can customise the build flavour, choose the packages to build, add file/package/platform-specific command line flags, etc. * https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md: A description of the "test" rule and all the options it supports. The documentation can surely be improved, so please do not hesitate to send us feedback and suggestions here, or even better on Trac: make sure you choose the component "Build System (Hadrian)" when creating a new ticket. You need Hadrian Hadrian is new, requires time to learn, and still has rough edges, but it has been developed to make your lives better. Here are a few advantages of Hadrian over the Make-based build system: 1) Hadrian is more reliable. Hadrian can capture build dependencies more accurately, which means you rarely (if ever) need to do a clean rebuild. 2) Hadrian is faster. Hadrian is faster for two reasons: (i) more accurate build dependencies, (ii) tracking of file contents instead of file modification times. Both allow you to avoid a lot of unnecessary rebuilds. Building Hadrian itself may take a while but needs to be done only once. 3) Hadrian is easier to understand and modify. You no longer need to deal with Make's global namespace of mutable string variables. Hadrian is written in the language you love; it has modules, types and pure functions. If you come across a situation where Hadrian is worse than the Make build system in any of the above aspects, this is a bug and you should report it. Helping Hadrian === The best way to help is to try Hadrian, and let us know how it goes, what doesn't work, what's missing for you, what you think should be easier, and so on. Below is a list of known issues that we are in the process of fixing or that we will be tackling soon: *Stage 2 GHC should be dynamically linked most of the time, but it never is, currently. See https://ghc.haskell.org/trac/ghc/ticket/15837 *There are about a dozen of failing tests in the GHC testsuite, some related to #15837. *Binary distributions haven't been thoroughly tested on many platforms (only some Linux flavours). There will definitely be some issues here. For example, the binary distribution rule currently fails on Windows: https://ghc.haskell.org/trac/ghc/ticket/16073. *There is no "validate" rule yet, only "test", but we have all the pieces to make this happen and it has a very high priority. *There are issues with building cross compilers: see https://ghc.haskell.org/trac/ghc/ticket/16051. We are likely missing some features compared to the Make build system, but none of them should take a lot of time to implement at this point. If you spot one, let us know! We'll do our best to implement it (or help you do it) as soon as we can. It is useful to look at the existing Hadrian tickets before submitting new ones, to make sure that the issue or idea that you would like to talk about hasn't been brought up yet: https://ghc.haskell.org/trac/ghc/query?status=!closed=Build+System+(Hadrian). Of course, we welcome your code contributions too! Several GHC developers have a good understanding of Hadrian codebase and will be able to help you. To find their names, have a look at the list of recent Hadrian commits: https://gitlab.haskell.org/ghc/ghc/commits/master/hadrian. As you can see, Hadrian is actively developed by many people, and we hope
