Note that Travis CI time is a sum of all operations, including
fetching/saving caches etc.
Opening the build log and looking for the compilation might be more
revealing. For example, 7.10 seems ~10 seconds, 8.2.1 seems ~50 seconds.
There are two issues I can see with this, that should be addresse
I tried the package with 8.2.1 and 8.0.2 and both build in less than 5
seconds with quite a large amount of variability. As Robin points out,
there are varying factors which can account for longer build times on
Travis.
On Tue, Jul 4, 2017 at 8:16 AM, Deest, Gaël wrote:
> Hi all,
>
> As you are p
Thanks Gael.
As you may know, we’ve focused a lot on compile time in the last year or so,
and 8.4 is a lot faster. I think there are still plenty of bad cases, but
things are better.
Our compile-time perf page is here:
https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler
It links to a
Another things to note about 8.2 build times is that a bulk of the time is
probably being spent during the linking phase. This is because GHC 8.2 has
switched over to split-sections by default, but unfortunately, old versions
of the BFD linker take a long time to link code that uses split-sections
Ryan Scott writes:
> Another things to note about 8.2 build times is that a bulk of the time is
> probably being spent during the linking phase. This is because GHC 8.2 has
> switched over to split-sections by default, but unfortunately, old versions
> of the BFD linker take a long time to link c
On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote:
> Ryan Scott writes:
>
>> Another things to note about 8.2 build times is that a bulk of the time is
>> probably being spent during the linking phase. This is because GHC 8.2 has
>> switched over to split-sections by default, but unfortunately, ol
Evan Laforge writes:
> On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote:
>>
>> In short, ./configure will now choose to use ld.gold or ld.lld if
>> available (although this can be disabled using the --disable-ld-override
>> configure flag).
>
> Just from curiosity, does this apply to OS X? Of c
For those of us who are on macOS,
you usually do not have any gcc, it’s all clang behind the curtains. E.g.
see
$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42
Moritz Angermann writes:
> For those of us who are on macOS,
...
> Thus, if you end up having the llvm tools (and ld.lld) in your PATH, you
> will need to set `--disable-ld-override` during configure on macOS, or your
> ghc build will fail, because you end up trying to link MachO object files
>
On 07/ 8/17 01:33 AM, Ben Gamari wrote:
8.2 will prefer both gold and lld over bfd ld. However two conditions
must hold for these to be used,
* The ld.lld/ld.gold executable must be in $PATH (or explicitly named
by passing the LD variable to configure)
* $CC must understand the `-fuse-l
10 matches
Mail list logo
