| I can do the former, but the latter needs to be done by a member of the
| “ghc” on GitHub. I can do the latter (and keep managing the travis
| instance) if someone adds me to the organization...
Johachim, you contribute a lot, thank you. You should be a member of the
group!
Who decides
Hello Joachim,
On 2014-07-11 at 12:36:23 +0200, Joachim Breitner wrote:
with all packages as submodules, ghc-complete (which is basically a git
repository tracking the „fingerprint“ of the main repository) is
obsolete. So we could move the travis-checking of the main line to run
on the ghc
Hi,
Am Freitag, den 11.07.2014, 13:39 +0200 schrieb Herbert Valerio Riedel:
Travis-CI is enabled for ghc/ghc with Build only if .travis.yml is present
I'd suggest you create a self-contained .travis.yml in a wip/ branch (
as that should trigger travis-builds) and tweak it there until it's
On 2014-07-11 at 14:12:14 +0200, Joachim Breitner wrote:
[...]
heh, fat chance. Travis is unable to check out the repository from
github, because the submodule URL points to something invalid:
Cloning into 'libraries/Cabal'...
fatal: remote error:
ghc/packages/Cabal is not a valid
Hi,
Am Freitag, den 11.07.2014, 14:48 +0200 schrieb Herbert Valerio Riedel:
So travis does a recursive clone by default? So that we can't even
easily inject
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#AlternativeGitHubrewriterules
?
If I get the docs
On Fri, Jul 11, 2014 at 1:39 PM, Herbert Valerio Riedel wrote:
Btw, can we get a clang-based build-config in the matrix as well?
Assuming tests are run, what about enabling -fsanitize switches?
There are more switches, but the following are documented to work in
both Clang and GCC:
