Alp
You've written a helpful wiki page describing how to use Hadrian
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
Could you document where build-products live? I often look at .hi files.
Could you add
* How to do the equivalent of "sh validate"
*
Andrey and other Hadrian heros
Just to say that I am 100% stalled on using Hadrian because the in-tree binary
uses the wrong library files. I reported this a few weeks ago, but it still
seems unchanged
Simon
Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version
The Glorious Glasgow Haskell
I am working on a branch of GHC, actually on !8210. I have rebased on
master. Then I say
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
get the right command line to do that from the build log?
Where is the "how to use Hadrian" wiki page? I know you've been writing one.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
s to
documents that answer some of your questions. I would perhaps recommend
that you (and others) wander through that document and any other doc
that seems relevant to your interests/workflow (e.g testsuite.md,
user-settings.md in your case)
Hadrian is however currently lacking some knob
the start of
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md?
And point to https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
from the more comprehensive page.
So in the end they both refer to each other
S
From: Alp Mestanogullari
Sent: 09 January 2019 11:10
To: Si
;s README [1] is a better
place to start from in general
OK super: can you say that at the start of
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md?
And point to
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md
from the more comprehensive page.
So in t
s a quick
reference/cheatsheet (hence the _very_ lightweight format) for people
familiar with the make build system. Hadrian's README [1] is a better
place to start from in general
OK super: can you say that at the start of
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.
As suggested, I'm trying out Hadrian. I have a few questions.
- After building GHC the first time, I often go into the /ghc directory and
then do `make 2` to build just the stage-2 compiler. Is that now the same as
`build --freeze1`? It would seem not (I haven't tested), because run
Hi Simon,
Apologies it's taking so long. It's not obvious how to fix this properly, and
as a temporary workaround we could create a top-level wrapper script, say
`ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like
Hadrian itself does during the build.
Will
as a temporary workaround we could create a top-level wrapper script, say
`ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like
Hadrian itself does during the build.
That sound fine, thanks. Same for ghc-stage2.sh?
My difficulty is that as of today I simply do not know
script, say
> `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like
> Hadrian itself does during the build.
>
> That sound fine, thanks. Same for ghc-stage2.sh?
>
> My difficulty is that as of today I simply do not know how to invoke my
> freshly b
From: Matthew Pickering
| Sent: 15 April 2019 13:40
| To: Simon Peyton Jones
| Cc: Andrey Mokhov ; ghc-devs@haskell.org
| Subject: Re: Hadrian
|
| Does the stage2 compiler which is found in `stage1/bin/ghc` not work for
| you? I thought the issue was that the stage1 compiler doesn&#
sounds good to me!
| -Original Message-
| From: Moritz Angermann
| Sent: 15 April 2019 14:29
| To: Simon Peyton Jones
| Cc: Matthew Pickering ; Andrey Mokhov
| ; ghc-devs@haskell.org
| Subject: Re: Hadrian
|
| I guess we could add
|
| $root/ghc-stage1 (shell script
Hi all,
Here is a patch for generating wrapper scripts from Hadrian:
https://gitlab.haskell.org/ghc/ghc/merge_requests/780
While it's being reviewed and merged, you can create script
`/ghc-stage1` with the following line yourself:
"_build/stage0/bin/ghc.exe" "-package-
(apols for premature send)
I am working on a branch of GHC, actually on !8210. I have rebased on
master. Then I say
hadrian/build
and I get the log below. It falls over saying
No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
Surely that should not happen?
I'll try
Hi Simon,
You have to re-run `./configure` in cases like this. It's because
`compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by
`./configure`. This isn't tracked by Hadrian.
>Surely that should not happen?I'll try make clean; but isn't this a bug?
Hope
still
exist in your hadrian _build directory, hadrian believes it a generated
file (like GHC.Settings.Config or
All you need to fix this is to delete the _build directory, which is
the hadrian build root you are using. It is advisable to do this after
rebasing, especially if the rebase involves
>
> It is advisable to do this after
> rebasing, especially if the rebase involves changes to the module
> structure or build system.
But *any* commit could involve such a change. Isn't it a goal of Hadrian
to respond to, well, changes? For example, it is clever enough t
that file no longer exists in the
compiler/ source directory, but presumably some references to it still
exist in your hadrian _build directory, hadrian believes it a generated
file (like GHC.Settings.Config or
All you need to fix this is to delete the _build directory, which is
the hadrian build root
Yes, but as Sylvain noted, the configure step (which generates ghc.cabal
and so is particularly sensitive to changes in module structure) is not
tracked by hadrian at the moment. We could in principle fix this, and
as also noted by Sylvain this will become much easier once Make no longer
exists
OK. So it's a bug. Do we have an open Hadrian ticket to track it? If
not, might you open one?
Make *already *no longer exists, incidentally. Nowadays we need ghc-9.2
to build HEAD, and make doesn't work with ghc-9.2 for some reason. So I
believe that make is dead for HEAD at lea
I'm in a GHC tree, built with Hadrian, I'm getting this red problem. But
compilation has got way past compiling base.
why is it looking in my .ghc/... directory? It should be looking in my
build tree.
Simon
bash$ ~/code/HEAD-1/_build/ghc-stage1 -c Foo.hs
Loaded package environment
Hello everyone,
This is a quick update on the current state of Hadrian, the new build system
for GHC (https://github.com/snowleopard/hadrian).
Current status
We've been slowly but steadily fixing issues, and are getting close to the
stage where GHC-devs can start using Hadri
Hi Andrey,
Given that 8.2.1 is finally starting to come together, now is probably a
good time to start reflecting on what will come in 8.4. I think it would
be great if we could finally get Hadrian into the tree for the 8.4
release. It would be even better if we could flip over to Hadrian as the
Hi all,
As a user who tried to be an early adopter of Hadrian, I can attest to
Andrey's remarks about GHC progress sometimes (frequently?) breaking
Hadrian.
Ben, Andrey - how about this strawman proposal:
we merge Hadrian into GHC *now*, not because ./validate with Hadrian
works (it doesn&
"Boespflug, Mathieu" writes:
> Hi all,
>
> As a user who tried to be an early adopter of Hadrian, I can attest to
> Andrey's remarks about GHC progress sometimes (frequently?) breaking
> Hadrian.
>
> Ben, Andrey - how about this strawman proposal:
>
> we
Hi Mathieu,
Yes, in principle we can merge right now, as long as it's clear that Hadrian
still requires more work before taking over.
My only concern is that merging will make it more difficult for us to quickly
iterate on Hadrian: the GitHub workflow is more convenient (at least for me)
Andrey Mokhov writes:
> Hi Mathieu,
>
> Yes, in principle we can merge right now, as long as it's clear that Hadrian
> still requires more work before taking over.
>
> My only concern is that merging will make it more difficult for us to
> quickly iterate on Hadrian: t
Thanks Ben,
Just to clarify: By history I mean not just commits, but GitHub issues and PRs
as well -- together they contain a lot of valuable interlinked information for
GHC/Hadrian developers.
> That is pretty much precisely the use-case which
> git subtree was designed to address. Thi
Andrey Mokhov writes:
> Thanks Ben,
>
> Just to clarify: By history I mean not just commits, but GitHub issues
> and PRs as well -- together they contain a lot of valuable interlinked
> information for GHC/Hadrian developers.
>
Well, the GitHub repo will still exist. Is th
Hi Ben,
> Well, the GitHub repo will still exist. Is that enough?
Yes, but I think I'll need to do some clean up in the code so that it's obvious
where to look for answers. For example, here is a random comment from a Hadrian
source file:
-- Objdump is only required on OpenBS
Hi,
two things.
a) why a git subtree if we keep working on github with hadrian, wouldn't that
imply using a submodule? We use submodules for
all the other ghc boot libs that are not part of the tree and are developed
on github as well, no? As far as I understand
a subtree,
Hi Moritz (et al.),
On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:
> a) why a git subtree if we keep working on github with hadrian, wouldn't that
> imply using a submodule? We use submodules for
>all the other ghc boot libs that are not part of the tree and are
> On Oct 20, 2017, at 6:24 PM, Herbert Valerio Riedel
> wrote:
>
> Hi Moritz (et al.),
>
> On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:
>
>> a) why a git subtree if we keep working on github with hadrian, wouldn't
>> that imply using a subm
Hi Moritz and Herbert,
Thank you for detailed comments! We clearly need to carefully think through our
options for merging Hadrian.
Can I invite you both and everyone else to continue the discussion in
https://github.com/snowleopard/hadrian/issues/440? Long email threads tend to
become hard
Andrey Mokhov writes:
> Hi Moritz and Herbert,
>
> Thank you for detailed comments! We clearly need to carefully think through
> our options for merging Hadrian.
>
> Can I invite you both and everyone else to continue the discussion in
> https://github.com/snowleopard/had
Sigh. As an inconvenient workaround, I tried adding {-# OPTIONS_GHC
-dverbose-core2core #-} to GHC.Real, and then doing
cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".."
in hadrian/
That did recompile GHC.Real - but all the debug output disappeared!
I tr
Simon,
If you want to see all command lines, you can pass '--verbose' or '-V' flag to
Hadrian and it will then print out everything it does.
But you can also choose which particular command lines to print in
UserSettings, see:
https://github.com/snowleopard/hadrian/
Hello Simon, Andrey,
For “How to use Hadrian wikipage”, maybe Simon wanted this one from the GHC
Wiki:
https://ghc.haskell.org/trac/ghc/wiki/Building/Hadrian/QuickStart
It does mention the verbose flag, but does not really explain that you can
get what Simon wants, I believe.
--
Best wishes
| If you want to see all command lines, you can pass '--verbose' or '-V'
| flag to Hadrian and it will then print out everything it does.
But I am not invoking Hadrian. I am saying (on your instructions)
cabal new-run hadrian -- -c -j4 --flavour=quick --directory=
> How do I "pass --verbose to Hadrian"?
Like this:
cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." -V
Everything after "--" in this command line are flags passed to Hadrian.
Everything before are flags passed to Cabal. (I hope we'll fix t
Very confusingly
https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#verbose-command-lines
speaks about verboseCommmands PLURAL, whereas it should say verboseCommand
SINGLUAR.
Moreover, what is the language things you can say (i.e. where is it
documented). The
s in the rest of the
doc/user-settings.md document, for example here:
https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#command-line-arguments.
The `input` and `output` predicates accept Shake's `FilePattern` as parameters
-- see the documentation for it here:
ht
Thanks!
It's helpful to tell me, but more helpful still to augment the "How to use
Hadrian" documentation, as you suggest.
Simon
| -Original Message-
| From: Andrey Mokhov
| Sent: 04 September 2018 18:49
| To: Simon Peyton Jones ; Alp Mestanogullari
|
| Cc: ghc-devs
In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do
this with devel2, and I'd prefer Hadrian didn't, too.
Maybe I'm not really on the devel2 flavor?
> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg wrote:
>
> As suggeste
`make 2` should be somewhat equivalent to `./hadrian/build.sh
_build/stage1/bin/ghc` I think.
The problem is with the devel2 flavour itself. Tracked by
https://ghc.haskell.org/trac/ghc/ticket/16210
The `hadrian/build.sh` script uses `cabal new-build` so the
dependencies should be shared already
Worth noting that Hadrian additionally defines a set of so-called phony targets
for packages and executables, so `./hadrian/build.sh --freeze1
build/stage1/bin/ghc` can also be expressed independently from your build root
as `./hadrian/build.sh --freeze1 stage2:exe:ghc-bin`.
Alec
> On Jan
Maybe I'm just lazy, but would it be possible to shorten these? Specifically,
could there be a root-level file `build` that triggers Hadrian? That way, I
could just say ./build instead of hadrian/build.sh.
Actually, even that isn't quite right. It is common, for example, for me to b
Hi Richard,
First of all, thank you trying Hadrian and generating several new bug reports.
This is very helpful!
> I think it would be very convenient to make a script we can all install (in
> our PATH) that will
> search for hadrian's build.sh and run it. Then, we can just s
Hadrian and generating several new bug reports.
This is very helpful!
I think it would be very convenient to make a script we can all install (in our
PATH) that will
search for hadrian's build.sh and run it. Then, we can just say `build` (or
whatever we name
the script) anywhere in a tree. Of c
Hello Shake/Hadrian contributors and the like,
Recently I've been putting Hadrian's fsatrace linting feature to good
use, tracking down missing dependencies in Hadrian. Ultimately, we want
to use shake's cloud build / shared cache feature and ensure it works
across CI builds
Hi Vlad,
Are there imminent plans to update hadrian/stack.yaml with something like,
```
# Specifies the GHC version and set of packages available (e.g., lts-3.5,
nightly-2015-09-21, ghc-7.10.2)
resolver: lts-13.21
```
I think this is necessary to get the recent happy upgrade?
--
Shayne Fletcher
Hi Simon,
Matt should have fixed it with
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8556
Sylvain
On 12/07/2022 14:24, Simon Peyton Jones wrote:
I'm in a GHC tree, built with Hadrian, I'm getting this red problem.
But compilation has got way past compiling base.
s,
Douglas Wilson
On Tue, Jul 12, 2022 at 1:24 PM Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:
> I'm in a GHC tree, built with Hadrian, I'm getting this red problem. But
> compilation has got way past compiling base.
>
> why is it looking in my .ghc/... d
Hi Ben and all,
I'm strongly in favour of switching GHC to Hadrian as soon as possible, because
just keeping up with changes in GHC takes substantial effort. Zhen Zhang (in
CC) has been recently helping me, and I hope he could make good progress
towards this goal as part of his Summ
Andrey Mokhov writes:
> Hi Ben and all,
>
> I'm strongly in favour of switching GHC to Hadrian as soon as
> possible, because just keeping up with changes in GHC takes
> substantial effort.
I can imagine; I feel like there has been even more build system churn
in GHC t
Dear GHC developers,
As some of you might have already noticed, Hadrian has finally been merged into
the GHC tree. However it's not yet time to celebrate - there are still many
issues that need to be addressed before the Make-based build system may retire.
Have a look at the README if
Hi,
I'm trying to build with hadrian (
https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/)
I get an error when running: stack exec hadrian -- --directory ".." -j
--flavour=quickest --configure
md5sum: 'standard input': no properly formatted MD5 checksum line
Hi everyone,
For the past few months I have been using Hadrian for the majority of my
GHC builds. In due course I have encountered a few papercuts:
* hadrian/cabal.build.sh is quite wordy (#16250); moreover, you need to
be in the source root to invoke it (#16667)
* editing hadrian.settings
For reference, hadrian-util lives at:
https://gitlab.haskell.org/bgamari/hadrian-util
I quite like the idea of trying out improvements to the UX via an
external wrapper. For wider adoption, we'd have to distribute it in a
nicer way I suppose, but taking this one step at a time sounds
This looks really useful, and might bridge the gap between the UX I'm used to
and Hadrian, allowing me to adopt Hadrian sooner than I otherwise would.
However, I would be disappointed to see hadrian-util still in active use when
`make` is removed (#17527). I'm glad to see Ben'
GHC newcomer here -- attempting to work on my first patch.
I decided to try Hadrian, but ran into a problem.
I think I obtained the source using
> git clone --recursive https://gitlab.haskell.org/ghc/ghc
Then:
> ./boot && ./configure
> hadrian/build.sh -j --flavour=devel2
This
transitive inputs.
I think for now we are really keen to make Hadrian a cloud build system, but
whether shallow builds are valuable enough is not clear. Maybe not. Therefore,
I’d say we don’t need to track transitive inputs right now. Furthermore, if we
were to track all transitive inputs, we
an input would be fatal (i.e.
unsound). It’s sound to list too many inputs, but doing will reduce the
usefulness of the cache.
* In contrast, to get a correct Hadrian build, it suffices to list all the
direct imports (= shallow depdendencies) of the thing being compiled. We’ll
bring those
From: ghc-devs On Behalf Of Andrey Mokhov
Sent: 27 March 2019 15:06
To: David Eichmann ; Neil Mitchell
Cc: GHC developers
Subject: RE: Hadrian Transitive Dependencies
Hi David,
We had a discussion about this with Neil some time ago, and I think we had the
following list of progressively
https://gitlab.haskell.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&search=%22ghc+-M%22
seems to suggest this never made it into a ticket. I searched in the
Hadrian github repo as well, no luck there either. It certainly came up
in various discussions I've had t
I also remember this discussion.. I think it was in the context of
optimising hadrian.
On Wed, 27 Mar 2019, 15:56 Alp Mestanogullari, wrote:
>
> https://gitlab.haskell.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&search=%22ghc+-M%22
> seems to suggest this
ith shallow (deferred) materialisation of build
artefacts: **all transitive inputs and direct outputs must be
declared**. Let’s say you’d like to download the resulting GHC binary
directly, without materialising any intermediate artefacts. Then
you’ll need to know GHC’s ultimate transitive inp
imon
From: ghc-devs On Behalf Of David Eichmann
Sent: 27 March 2019 17:12
To: Andrey Mokhov ; Neil Mitchell
Cc: GHC developers
Subject: Re: Hadrian Transitive Dependencies
Hello,
To reiterate some definitions consider this scenario:
* A.hs imports B.hs and B.hs imports C.hs
* `g
be sure that
every deep dependency was either ‘needed’ or was reflected in the contents
(perhaps via a fingerprint) another ‘needed’ thing.
Simon
From: ghc-devs On Behalf Of David Eichmann
Sent: 27 March 2019 17:12
To: Andrey Mokhov ; Neil Mitchell
Cc: GHC developers
Subject: Re: Hadria
is to simply silence the linting using `trackAllow
["//*.hi"]` for haskell object rules. Then I can continue tracking down
other missing dependencies in Hadrian with fsatrace linting.
On 3/27/19 5:38 PM, Andrey Mokhov wrote:
Simon's insight is great: if deep dependencies are capt
18:04
To: Andrey Mokhov ; Simon Peyton Jones
Cc: Neil Mitchell ; GHC developers
Subject: Re: Hadrian Transitive Dependencies
Ah! I see. This is a bit disappointing as it reduces the utility of fsatrace
linting: the programmer is forced to decide if shallow dependencies are
sufficient (changes
I can continue tracking down other missing dependencies in
> Hadrian with fsatrace linting.
Yes, this looks like the best approach for now.
Cheers,
Andrey
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I've started a wiki page to document some of this discussion
https://gitlab.haskell.org/ghc/ghc/wikis/Developing-Hadrian. We'll also
need to deal with ouputs as well as inputs (dependencies) soon. Hence
I've expanded a bit on my understanding of rule *outputs* and added the
ter
avoid breakage in the future?
- Vlad
> On 15 May 2019, at 04:36, Shayne Fletcher via ghc-devs
> wrote:
>
> Hi Vlad,
>
> Are there imminent plans to update hadrian/stack.yaml with something like,
> ```
> # Specifies the GHC version and set of packages available (e.g., lts
Hi Vlad,
On Wed, May 15, 2019 at 2:20 AM Vladislav Zavialov
wrote:
> I don’t use ’stack’ to build GHC and CI doesn’t check it, so I think I
> missed this one. Thanks for bringing this up, have you already checked
> locally that ‘lts-13.21’ fixes the issue (if so, perhaps submit an MR with
> your
Windows builds with hadrian are currently failing with "file does not exist
and no build rule available"
`_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas
on how to overcome that?
--
Shayne Fletcher
Language Engineer
c: +1 917 699 7763
e: shayne.fletc...@daml.c
I'm trying to isolate the commit that's causing this, but the deal is on
MacOS I'm seeing stage1 `ld` crashes linking `HStime`:
```
0 0x1052e2748 __assert_rtn + 129
1 0x1052be30f ld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster,
ld::Fixup::Kind, bool, char const*) + 95
2 0x1052e8736
mach_o
Building `HEAD` just now with `hadrian/build-stack --flavour=quickest -j`,
I get a link failure for stage1 `bin/ghc`:
```
ld: library not found for -lHSrts-1.0_thr_l
```
I'll try another flavour or something but in the meantime is this ringing
any bells?
--
Shayne Fle
Congrats Andrey,
> 2) A major refactoring by Moritz Angermann is on the way. Moritz is primarily
> interested in cross compilation, but to make it work he had to get rid of the
> ghc-cabal utility, reorganise the build tree, and make numerous other
> improvements to Hadria
Hello everyone,
A bit over a month ago we merged hadrian into the ghc tree as a subtree.
Unfortunately, those working on Hadrian have found the subtree mechanism
to provide a rather poor developer experience. Consequently, today I
will be ripping out the subtree and replacing it with a submodule
Hi Andrey and Alp,
Before ICFP we concluded that we will merge Hadrian into the GHC tree.
This unfortunately took a back-seat priority-wise while I sorted out
various release things but I think we are now in a position to make this
happen.
Andrey, would you be okay with my merging Hadrian as-is
Hi everyone,
Hadrian is now merged into the GHC tree.
For better or worse, due to the large number of merge commits in the
Hadrian repository we were unable to squash the early history of the
project.
If you encounter trouble using the Hadrian build system please file a
ticket on Trac, setting
the Hadrian move – I’ve fixed this.
Cheers,
Andrey
Forwarded Message
Subject:
Hadrian build failed
Date:
Thu, 1 Nov 2018 20:33:14 +0200
From:
Yotam Ohad <mailto:yotam2...@gmail.com>
To:
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Hi,
I'm try
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
e properly?
Cheers,
Andrey
--
Message: 3
Date: Fri, 8 Feb 2019 21:57:03 -0800
From: Eric Crockett
To: ghc-devs
Subject: Cannot build with Hadrian
Message-ID:
Content-Type: text/plain; charset="utf-8"
GHC newcomer here -- attempting to work on my first
Hi Eric,
Good to hear you managed to build GHC both with Make and Hadrian.
Best wishes with your first GHC patch!
Cheers,
Andrey
From: Eric Crockett [mailto:ecrocke...@gmail.com]
Sent: 09 February 2019 18:21
To: Andrey Mokhov
Subject: Re: Cannot build with Hadrian
Andrey,
I had already
I guess,
On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher
wrote:
> Windows builds with hadrian are currently failing with "file does not
> exist and no build rule available"
> `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas
> on how to overcom
Hello!
Could you create a ticket about this with all the relevant details (OS X
version, boot ghc version, commit, hadrian command, etc), and the
'hadrian' label? You should even feel free to mention @snowleopard and
@alp there.
Cheers
On 22/05/2019 19:37, Shayne Fletcher vi
rote:
Windows builds with hadrian are currently failing with "file does
not exist and no build rule available"
`_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have
an ideas on how to overcome that?
relates to 0af519ac583c3544b1c4b1315b38ba0174d3c
Here you go Alp https://gitlab.haskell.org/ghc/ghc/issues/16685. Hope this
helps!
On Wed, May 22, 2019 at 1:41 PM Alp Mestanogullari
wrote:
> Hello!
>
> Could you create a ticket about this with all the relevant details (OS X
> version, boot ghc version, commit, hadrian command, e
; Here you go Alp https://gitlab.haskell.org/ghc/ghc/issues/16685. Hope
> this helps!
>
> On Wed, May 22, 2019 at 1:41 PM Alp Mestanogullari
> wrote:
>
>> Hello!
>>
>> Could you create a ticket about this with all the relevant details (OS X
>> version, boot
o:a...@well-typed.com>> wrote:
Hello!
Could you create a ticket about this with all the relevant
details (OS X version, boot ghc version, commit, hadrian
command, etc), and the 'hadrian' label? You should even feel
free to mention @snowle
No comments on this. Maybe I should raise a ticket? Anybody got an email
address to ping David on?
-- Forwarded message -
From: Shayne Fletcher
Date: Wed, May 22, 2019, 13:03
Subject: Re: [hadrian/windows] build broken
To: GHC developers
I guess,
On Wed, May 22, 2019 at 12:27
Below is an error message I have seen a number of times after
rebasing my git worktree, i.e. this is how to "reproduce":
git fetch origin
git rebase origin/master
git submodule update
./hadrian/build.sh
(Obviously some details are elided, and this is not a complete re
Shayne Fletcher writes:
> Building `HEAD` just now with `hadrian/build-stack --flavour=quickest -j`,
> I get a link failure for stage1 `bin/ghc`:
> ```
> ld: library not found for -lHSrts-1.0_thr_l
> ```
> I'll try another flavour or something but in the meantime is t
Sounds good! Hopefully this doesn’t cause a flood of commit messages.
_ara
> On 8 Dec 2017, at 18:50, Ben Gamari wrote:
>
> Hello everyone,
>
> A bit over a month ago we merged hadrian into the ghc tree as a subtree.
> Unfortunately, those working on Hadrian have found the
Great! A submodule makes a lot more sense to me, at least short term. I
would hope that medium term the development processes of GHC-as-a-whole and
Hadrian(-a-part-of-GHC) can converge, so that a submodule is no longer
necessary. Submodules do have their downsides and it would be odd for such
a
Hi Ben,
Yes, I'm fine to merge, but we should make it clear that Hadrian should not be
used just yet:
1) It is currently broken due to some recent changes in GHC.
2) Alp made tremendous progress with fixing the testsuite failures, but there
are still some failures left.
3) There are
1 - 100 of 202 matches
Mail list logo
