Building ghc on Windows with msys2

[Thomas Miedema]

Forgot to add. Here is a script I used to test this approach, using
libffi-tarballs as an example:
https://gist.github.com/thomie/260755a5ab79f020fb79

On Mon, Sep 29, 2014 at 11:40 AM, Thomas Miedema <thomasmiedema at gmail.com>
wrote:

>
>> > 3. Why is ghc-tarballs a git repository? That does not seem very wise.
>>> [...]
>>> > Could we have a stable folder under haskell.org/ to put the files in,
>>> to
>>> > make sure that they never go away, and just wget/curl them from there?
>>>
>>> http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887
>>>
>>
>> Hmm, that was a while ago. Whom should I contact to get the files
>> deployed under haskell.org?
>>
>
> Here's a different solution to the 'big binary blobs' problem:
>
> * Keep the ghc-tarballs git repository, and add it as a submodule
> * Make sure it doesn't get cloned by default
> git config -f .gitmodules submodule.ghc-tarballs.update none
> * Windows developers run (after initial clone --recursive of the ghc
> repository, one time):
> git config submodule.ghc-tarballs.update checkout
> git submodule update --depth=1
> * After that, windows developers run the normal:
> git submodule update
>
> The advantages are:
> * only the most recent ghc-tarballs commit gets cloned initially
> * subsequent 'git submodule update' runs will make sure always the most
> recent version of ghc-tarballs is available
> * full history of ghc-tarballs is tracked, easier bisecting
> * no extra scripts needed
>
> I don't know how much space overhead git adds. wget-ting just the files
> themselves might still be faster.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140929/8730dbc3/attachment-0001.html>