That’s a very good point, and should be a good solution for now.
_ara
> On 30 Aug 2017, at 18:28, Phyx wrote:
>
> That's certainly a possibility, though note that this is only an issue for
> compiling stage2, not end user programs.
> Since it's only for compiling ghc we don't have to include
That's certainly a possibility, though note that this is only an issue for
compiling stage2, not end user programs.
Since it's only for compiling ghc we don't have to include it in the
bindist so license would be less of an issue I think.
I'll modify the scripts to pull it automatically when I sub
With a hit like that I think it should at least be highly publicised that
it can cause huge hits to compilation time. I would support bundling the
executable if it has a compatible license.
_ara
On Wed, Aug 30, 2017 at 3:19 PM, Ryan Scott wrote:
> Thanks for putting so much effort into this wor
Thanks for putting so much effort into this work, Tamar!
> When I do turn it on, by default you will get a large ~45min hit in compile
> time.
Yikes, that's really bad! Bad enough that I have to wonder: would it
be worth including genlib among the other executables that we bundle
with GHC? Fortu
Hi All,
I have just killed off dll-split, this means that you no longer need to
maintain a list
of modules in GHC.mk.
If you’re a non-Windows programmer you can stop reading here, for those that
build on Windows:
The replacement for dll-split is called gen-dll, and it is able to
Alan & Kim Zimmerman writes:
> I think you need to remove Ctype and Lexer from
> https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498
>
Thanks Alan!
That being said looking at the branch it's not entirely clear to me
where this change came from. It doesn't appear that Simon has added or
r
Thanks. Indeed, in parallel, I randomly tried that and indeed it’s going again
now.
· But why is dll-split running at all on Linux? Ben says: “I believe
dll-split is run to ensure that the module list remains consistent, even when
developers are building on non-Windows platforms
Simon Peyton Jones writes:
> It's just not my day.
> Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure
> in dll-split! Should dll-split be running at all on Linux
>
I'm looking into it. Give me a few minutes.
I believe dll-split is run to ensur
I think you need to remove Ctype and Lexer from
https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498
On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" wrote:
> It’s just not my day.
>
> Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in
> dll-split
It's just not my day.
Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in
dll-split! Should dll-split be running at all on Linux
The output it produces is below.
I'm totally stuck. Help desperately needed.
Simon
inplace/bin/dll-split compiler/stage2/build/.
r.haskell.org
>> | [mailto:nore...@phabricator.haskell.org]
>> | Sent: 15 December 2014 17:28
>> | To: Simon Peyton Jones
>> | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split
>> | problem with patch 'Make Core Lint check for locally-boun
on] [Build Failed] rGHC3f87866ad536: Fix dll-split
> | problem with patch 'Make Core Lint check for locally-bound…
> |
> | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split
> | problem with patch 'Make Core Lint check for locally-bound…!
> |
&g
ad536: Fix dll-split
| problem with patch 'Make Core Lint check for locally-bound…
|
| Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split
| problem with patch 'Make Core Lint check for locally-bound…!
|
| USERS
|simonpj (Author)
|GHC - Core/System FC (Au
13 matches
Mail list logo