On 07/10/13 22:06, Joachim Breitner wrote:
in the best scratch-an-itch-tradition I have created a special git
repository, called “ghc-complete”, which tracks the combined state of
all GHC-related repositories. It uses GHC’s fingerprint utility and
simply tracks the change of the fingerprint file over time:
https://github.com/nomeata/ghc-complete

The main use of this is to have a repo which I can enable to be
continuously checked by Travis (a free CI hoster). So instead of having
several people ask on IRC about what build or test suite failures are
actually not their fault, they can now simply check the travis page:
https://www.travis-ci.org/nomeata/ghc-complete/builds

This is great. With a bit of extra tool support for this we could actually do without submodules and go back to individual repos. Checking out a GHC revision in the past could consist of querying your ghc-complete repo for the fingerprint and then running the fingerprint tool.

(unless you haven't guessed, I'm not a huge fan of submodules)

The Travis tests are a bit stripped down, in order to finish reliably
before the 50 minute timeout, see
https://github.com/nomeata/ghc-complete/blob/master/validate.sh for the
precise options.

Did you try with and without -O0 for stage2? Last time we tried it was actually faster to turn on -O for stage2 if you're also running tests, because making the compiler run faster outweighs the time spent optimising it.

Cheers,
        Simon


The log files are too large for the JavaScript enhanced view on Travis.
So if you click on a specific build result, e.g.
https://www.travis-ci.org/nomeata/ghc-complete/builds/12216328
then better immediately browse to the raw build log (the rounded square
button in the top right corner with the four horizontal bars).

Another use of this repo might be bisecting a problem.

If you find this useful, I’d propose to let this run on git.haskell.org
proper, and also not as a cronjob (every 15 minutes at the moment), but
rather triggered by the actual pushes.

On my TODO list is to make the commit messages of the repository more
useful, by including the log of the new commits in it.

If (not sure if this is planned to that extend) eventually all related
repositories of GHC are submodules, this will have become obsolete.
Which of course is fine.

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to