[nightly] 15-Apr-2004 build of HEAD on Mingw32 (water)

[Simon Marlow]

I'd prefer not to be required to change my PATH to build GHC.  That
would be a pretty annoying restriction, because it's something you have
to do every time you want to do something in the build tree, rather than
just once when you configure the build.

The --with-gcc option is *supposed* to work properly.  Indeed, I use it
for testing different versions of gcc.  We should fix any cases where it
doesn't work properly.  Why is GMP still working?

As for binary distributions: they use a different method for finding
gcc, which is hardcoded into SysTools.hs.

--with-ld isn't necessary, because linking uses GCC.  As far as I can
see, --with-dllwrap is the only missing option.  Perhaps it could be
derived automatically from the --with-gcc option, pretty much like we
derive ghc-pkg from --with-ghc.

Cheers,
	Simon

On 20 April 2004 16:32, Sigbjorn Finne wrote:

> Quite the opposite, I'd say. We _want_ to always be using
> mingw-based tools, so insisting that they're available ahead
> of anything else sounds more robust. How do you know that
> the --with-gcc setting is honoured throughout all the Makefiles
> inside of fptools/ ? (which it isn't btw; cf. ghc/rts/gmp/ ) Using
> --with-gcc=... is also incompatible with creating portable binary
> distributions (as the path WhatGccIsCalled is hardcoded
> into main/Config.hs)
> 
> Presumably you want to add --with-ld=... too?
> 
> --sigbjorn
> 
> ----- Original Message -----
> From: "Simon Peyton-Jones" <simonpj at microsoft.com>
> To: "Sigbjorn Finne" <sof at galois.com>; "Mike Thomas"
> <mike.thomas at brisbane.paradigmgeo.com>
> Cc: <cvs-ghc at haskell.org>
> Sent: Tuesday, April 20, 2004 02:25
> Subject: RE: [nightly] 15-Apr-2004 build of HEAD on Mingw32 (water)
> 
> 
>> Well, if you are a Cygwin user, you might well expect to get the
>> Cygwin gcc when you type 'gcc' on the command line.  In general I
>> think it's more robust if mingw/bin doesn't appear in your PATH *at
>> all*.  That's why I always configure with --with-gcc=c:/mingw/bin/gcc
>> 
>> Sounds as if I should add
>> --with-dllwrap=c:/mingw/bin/dllwrap
>> 
>> Is that right?  Would configure understand that?  If not, could one
>> of you make it do so?  Let me know and I'll update the instructions.
>> 
>> 
>> (Of course, if you are using MSYS, then msys/bin will be in your
>> path, and that gcc probably is the same as mingw/bin/gcc; ditto
>> dllwrap.  But doing the --with stuff ensures you are independent of
>> the PATH and build platform.) 
>> 
>> Simon
>> 
>>> -----Original Message-----
>>> From: cvs-all-bounces at haskell.org
>>> [mailto:cvs-all-bounces at haskell.org] On Behalf Of Sigbjorn Finne
>>> Sent: 16 April 2004 01:16 To: Mike Thomas 
>>> Cc: cvs-ghc at haskell.org
>>> Subject: Re: [nightly] 15-Apr-2004 build of HEAD on Mingw32 (water)
>>> 
>>> Hi Mike,
>>> 
>>> good to hear that your change did the trick.
>>> 
>>> There may have been a good reason for arranging your PATH to
>>> not include mingw/bin ahead of cygwin path entries sometime
>>> in the distant past, but there's no reason not to do this today.
>>> I've been building fptools/ bits using that setup for years now.
>>> 
>>> --sigbjorn
>>> 
>>> ----- Original Message -----
>>> From: "Mike Thomas" <mike.thomas at brisbane.paradigmgeo.com>
>>> To: "Sigbjorn Finne" <sof at galois.com>;
>> <miketh at brisbane.paradigmgeo.com>
>>> Cc: <cvs-ghc at haskell.org>
>>> Sent: Thursday, April 15, 2004 17:01
>>> Subject: RE: [nightly] 15-Apr-2004 build of HEAD on Mingw32 (water)
>>> 
>>> 
>>>> Hi Sigbjorn.
>>>> 
>>>> Thanks for the excellent observation.
>>>> 
>>>>> I've seen this build error flit past for quite a while.
>>>> 
>>>> Yes; I'm so deeply enmired in GNU Common Lisp and Maxim Windows
>>>> ports  at the moment that I just run an occasional GHC build to
>>>> make myself feel better, but with little regard for the output.
>>>> 
>>>> 
>>>>> As far as I'm able
>>>>> to diagnose, it appears as if it might be due to a local mingw
>>>>> setup issue; I'm able to build HDirect just fine using multiple
>>>>> mingw versions/installations. 
>>>>> 
>>>>> 'dllwrap' perhaps being slurped in from a location other than the
>>>>> mingw installation tree? 
>>>>> 
>>>> 
>>>> Well spotted.  I just ran a test with the dllwrap entry in
>>>> "hdirect/mk/paths.mk" hardwired to the MinGW32 dllwrap and it all
>>>> went perfectly. 
>>>> 
>>>> This is going wrong because I am building according to the
>>>> instructions on the GHC web site which explicitly forbid putting
>>>> MinGW32 modules ahead of Cygwin (fow the past few months anyway, I
>>>> once used to ignore this aspect of the build instructions which I
>>>> regard(ed) as bad): 
>>>> 
>>>> "Do not add any of the mingw binaries to your path. They are only
>>>> going to get used by explicit access (via the --with-gcc flag you
>>>> give to configure later). If you do add them to your path you are
>>>> likely to get into a mess because their names overlap with Cygwin
>>>> binaries." 
>>>> 
>>>> I'll aim to do a build tonight with MinGW32 back in it's rightful
>>>> place in the path to make sure the whole system works correctly.
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>>> Mike Thomas.
>>>> 
>>> 
>>> _______________________________________________
>>> Cvs-ghc mailing list
>>> Cvs-ghc at haskell.org
>>> http://www.haskell.org/mailman/listinfo/cvs-ghc
> 
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc