Put GHC on travis for real
Hi, 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 repository directly. This would require * adding a .travis.yaml based on the contents of https://github.com/nomeata/ghc-complete/blob/master/.travis.yml and https://github.com/nomeata/ghc-complete/blob/master/validate.sh to the repository. * enabling Travis for this repository. 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... Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
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 repository directly. This would require
* adding a .travis.yaml based on the contents of https://github.com/nomeata/ghc-complete/blob/master/.travis.yml and https://github.com/nomeata/ghc-complete/blob/master/validate.sh to the repository. * enabling Travis for this repository.
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 ready for master Btw, can we get a clang-based build-config in the matrix as well? Cheers, hvr
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 ready for master
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 repository name Email support@github.com for help Clone of 'git://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed and clearly this happens before we get a chance to change them. Maybe it is finally time to re-think the directory layout on git.haskell.org to not use / and get rid of this problem for once and all. (Maybe with symlinks on git.haskell.org the old URLs can just continue to work.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
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 repository name Email support@github.com for help Clone of 'git://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed
and clearly this happens before we get a chance to change them.
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#Alte... ? If I get the docs right, you should be able to disable that and manually clone the submodules: http://docs.travis-ci.com/user/build-configuration/#Git-Submodules
Maybe it is finally time to re-think the directory layout on git.haskell.org to not use / and get rid of this problem for once and all. (Maybe with symlinks on git.haskell.org the old URLs can just continue to work.)
TBH, I don't like the idea of symlinks, as they would break the assumption in the server-side scripting that a repo is only accessible via a single path, which I'm sure would cause all sorts of subtle issues and confusing situations when you forget about that. Cheers, hvr
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#Alte...
?
If I get the docs right, you should be able to disable that and manually clone the submodules:
http://docs.travis-ci.com/user/build-configuration/#Git-Submodules
thanks, I’ll try that.
Maybe it is finally time to re-think the directory layout on git.haskell.org to not use / and get rid of this problem for once and all. (Maybe with symlinks on git.haskell.org the old URLs can just continue to work.)
TBH, I don't like the idea of symlinks, as they would break the assumption in the server-side scripting that a repo is only accessible via a single path, which I'm sure would cause all sorts of subtle issues and confusing situations when you forget about that.
And has a complete change or the URLs ever been considered? Now that people shouldn’t have to use ./sync-all any more, but can use standard tools to check out the repository, being able to clone from github directly and without such patching of paths might be desirable. (It wouldn’t help with cloning from any other fork, though. Seems to be an unavoidable issue with submodules.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
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: -fsanitize=address (2x slowdown) -fsanitize=undefined -fsanitize=thread (5x-15x slowdown) As the generated code will be slower, it may either complicate or limit its use, but -fsanitize is a useful tool to catch bugs. That said, it's probably easier to adopt on GHC builder slave nodes. http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
| 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 that? I know about GHC committers...is that the same as the ghc group on Github. Anyway I support adding Joachim! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 11 July 2014 11:36 | To: ghc-devs@haskell.org | Subject: Put GHC on travis for real | | Hi, | | 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 repository directly. This would require | | * adding a .travis.yaml based on the contents of | https://github.com/nomeata/ghc-complete/blob/master/.travis.yml | and https://github.com/nomeata/ghc-complete/blob/master/validate.sh to | the repository. | * enabling Travis for this repository. | | 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... | | Greetings, | Joachim | | | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nomeata@debian.org
participants (4)
-
Herbert Valerio Riedel -
Joachim Breitner -
Simon Peyton Jones -
Tuncer Ayaz