Hello, Bulat, On Thu, 26 Apr 2007 22:07:47 +0900, Bulat Ziganshin wrote:

can you please include in win32 distro c++ compiler, as it was done before and as it requested by trac ticket http://hackage.haskell.org/trac/ghc/ticket/1024 ?

This problem is already fixed. http://www.haskell.org/pipermail/cvs-ghc/2007-April/034976.html But current prep-bin-dist-mingw removes C++ header files by this part. rm -rf include/mingw/c++/ || echo "c++/ not there" I think we must remove this lines. But ... above lines' comment saids below. # g++-3/ subdir causes problems with installer tool (+ being a # troublesome character); leave out for now. #rm -rf include/mingw/g++-3/ || echo "g++-3/ not there" And I think this problem probably occurr on c++/ subdir, too. Because g++ is C++ compiler and there is no g++* directory in MinGW's sub-directory now. If Sigbjorn test with removing above part, and changing installer definition if that is needed, we can remove its part. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

Hello Bulat, I think that builders/distributers use "make binary-dist" to make binary distribution normally. http://hackage.haskell.org/trac/ghc/wiki/Building/Using#BootstrappingGHC "make binary-dist" calls prep-bin-dist-mingw to make Windows friendly distribution now. http://www.haskell.org/pipermail/cvs-ghc/2007-April/034978.html And before this change, we use "prep-bin-dist-mingw" explicitly to make Windows friendly distro. So I sent follow previous message. Because leaving incorrect prep-bin-dist-mingw lack some files that is important C++ for compilation. http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008738.html On Fri, 27 Apr 2007 01:29:26 +0900, Bulat Ziganshin wrote:

...

On Thu, 26 Apr 2007 22:07:47 +0900, Bulat Ziganshin wrote:

...

can you please include in win32 distro c++ compiler, as it was done before and as it requested by trac ticket http://hackage.haskell.org/trac/ghc/ticket/1024 ?

...

This problem is already fixed.

...

http://www.haskell.org/pipermail/cvs-ghc/2007-April/034976.html

the problem i said can't be fixed by anyone except than *builder* of windows distro. the problem is lack of files of c++ compiler and libraries in distro, not the ghc behavior

OK, builders is important role to make windows distro. But from above reasons, I think prep-bin-dist-mingw (this change "make binary-dist" behavior, not to change ghc behavior) also important role to make windows distribution. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

Hello Duncan, Saturday, April 28, 2007, 9:58:18 PM, you wrote:

...

can you please include in win32 distro c++ compiler, as it was done before and as it requested by trac ticket http://hackage.haskell.org/trac/ghc/ticket/1024 ?

Is it just me who thinks this is a silly idea? Why should GHC include a

if ghc developers think it's a bad idea they should remove this ticket i use ghc to develop haskell/c++ program. also, many libs today written in C++ and inclusion of c++ compiler will help to make more libraries available for ghc users alternative way may be inclusion of instructions how to add c++ compiler to ghc installation - it's not trivial because one need to know which gcc version should be used and which files copied -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Duncan Coutts wrote:

Is it just me who thinks this is a silly idea? Why should GHC include a C++ compiler?

I'm afraid it's just you. Like that someone who has indicated interest in haskell-c++ integration, I am interested in the prospect of mixing haskell with .NET languages, and not to mention that everyone, not just .NET literates, will benefit from the many libraries available in .NET. Can we also include a .NET runtime, a .NET documentation suite, all .NET libraries, a C# compiler, a VB compiler, and an F# compiler in a future GHC package for Windows? In fact also the corresponding Mono suite in the Linux case? Yes, I understand that a bridge between GHC and .NET does not exist yet, but consider this. In the spirit of "everyone is invited to help!" whenever there is a demand and not yet a supply in the Haskell community, we should encourage everyone to help add this missing bridge, and what better way is there if not ship a complete .NET suite in GHC so all interested parties can hack or test right away! And since this requires hacking the source code of GHC, wouldn't it be nice if the binary tarball also included the source tree? And also darcs since we will be crazy pushing and pulling? I am not done yet. An ideal of .NET, at least for frontline developers if not for corporate Microsoft, is to be portable throughout Windows, Linux (via Mono for example), BSDs, MacOS, Solaris,... At present let's say just Windows and Linux in practice. Someone on Windows Vista without Linux will not be able to test out the bridge under construction on Linux. Someone on Linux without Windows Vista will not be able to test out the bridge under construction on Windows Vista. This is a sorry state of affair. To help developers and testers (and remember "everyone is invited to help!"), I have this bright idea: The GHC binary for Vista should include Linux, and the GHC binary for Linux should include Vista! (The GHC binary for MacOS should include both Linux and Vista!) The last suggestion raises licensing issues, I am aware. We can't give away Vista just like that. We have to distribute it legally. The GHC team should extend itself (e.g., hire me!) to set up a lightweight e-Commerce company, authorized by Microsoft to sell Vista licences and releases. Then it can legally distribute GHC+Vista packages. (Of course you will have to pay, and the payment will find its way to Microsoft.) Collaboration with MSDN is also possible. This opens up a whole new dimension where no one has gone before! Just look at IBM: "We don't sell products, we sell services" brought them great success, in fact brought them out of great crisis into great success. If the GHC team also goes "we don't release compilers, we release complete platforms", the prospect is beyond imagination and its profoundness beyond expression. How should I file this to the bug track? Should I file one monolithic report containing the whole shebang above? Or should I re-factor it into a million piecemeals and file each individually?

On Sun, 2007-04-29 at 10:38 +0400, Bulat Ziganshin wrote:

Hello Albert,

Sunday, April 29, 2007, 2:51:24 AM, you wrote:

...

...

Is it just me who thinks this is a silly idea? Why should GHC include a C++ compiler?

...

.NET literates, will benefit from the many libraries available in .NET. Can we also include a .NET runtime, a .NET documentation suite, all .NET

you are lame.

Hia Bulat, It's really much better to criticise ideas rather than people personally, though I do understand that Albert was making a joke at your expense. In that situation its much better to try and ignore it rather than flaming. We do want to keep the various Haskell mailing lists civil :-)

java/c# libs can't be used with current ghc, so 99% of libs we may need are written in c/c++. making porting these lubs as hard as possible and then heroically rewrite them in pure haskell is one way, good for PhD and other pseudo-scientific activity. building bridges to the world of existing software is the way to the real haskell usage in big projects

Making it possible to use Haskell in mixed language projects with C++ and Java is obviously a good thing, but it's not really a scalable solution to distribute them all together. We should look at how to improve cabal+ghc to make it easier to use them as a component of a larger system. One example of this would be not requiring that ghc is used to do a final link, we should be able to make static libs and then link them using ordinary gcc. Duncan

On Mon, 2007-04-30 at 10:05 +0400, Bulat Ziganshin wrote:

Hello Duncan,

Sunday, April 29, 2007, 8:00:56 PM, you wrote:

...

...

java/c# libs can't be used with current ghc, so 99% of

...

Making it possible to use Haskell in mixed language projects with C++ and Java

how ghc/mingw can be used with java? :)

I expect it's quite tricky! :-) I'm not claiming it works or is easy, I was just commenting that making it possible or easier to use Haskell in larger mixed language projects is a good goal. Of course I've never tried it but I'd probably start by looking at the haskell-jvm-bridge (http://sourceforge.net/projects/jvm-bridge/) and seeing if that can be made to work with Sun Java on windows or perhaps GNU gcj works on mingw these days. Duncan

On Mon, 2007-04-30 at 11:02 +0400, Bulat Ziganshin wrote:

Hello Duncan,

Monday, April 30, 2007, 10:11:09 AM, you wrote:

...

...

how ghc/mingw can be used with java? :)

...

I expect it's quite tricky! :-)

...

I'm not claiming it works or is easy, I was just commenting that making

so, you agree that 99% of foreign-language libs that can be used with ghc/mingw are written either in C or C++?

But if you're using this to argue that we should ship a C++ compiler then it's just a circular argument. If we only ship a C compiler then 99% of foreign language libs that are easily usable with ghc/mingw are written in C. If we ship perl and python and whatever compilers then the foreign language libs that are easily usable would be in a wider range of languages. Remember that you don't even need a C compiler for ghc to be able to use C apis (or C apis exported from C++ libs). It's just not modular to bundle them all together. You can quite easily install a C, C++, Java or Pascal compiler and use that to build libs that export C apis and then use ghc (or any other Haskell impl) to use those apis. Duncan