64-bit windows version?
Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of mingw. The latest status update I could find is here: http://sourceforge.net/mailarchive/message.php?msg_id=460D8FC1.64E689DB%40de... Cheers, Simon
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of mingw.
Why do you need mingw? What's wrong with MSVC++? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
Hello skaller, Tuesday, June 19, 2007, 8:15:19 PM, you wrote:
are you plan to implement 64-bit windows GHC version?
Why do you need mingw? What's wrong with MSVC++?
really! Simon, how about unregisterised build? skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, 2007-06-20 at 07:34 +0400, Bulat Ziganshin wrote:
Hello skaller,
Tuesday, June 19, 2007, 8:15:19 PM, you wrote:
are you plan to implement 64-bit windows GHC version?
Why do you need mingw? What's wrong with MSVC++?
really! Simon, how about unregisterised build?
skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available?
Visual Studio Express is a Visual Studio 2005 IDE system for XP with some features disabled, the disabled features include interactive debugging, help, online news/blog stuff, etc: advanced IDE features. AFAIK the compilers are intact and can be used on the command line as well as from the IDE. I think you do need to download the platform SDK separately though. AFAIK on x86_64 platform, VS is a 32 bit program, as are the compilers, but they can generate 64 bit code (the 32 and 64 bit compilers are separate executables and run in distinct environments .. ) One thing to watch though: embedded assembler is gone in new MSVC++ compilers (due to multi-arch support I guess). However assembler works in 64 bit, Ocaml 64 bit for Windows uses it. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
Bulat Ziganshin wrote:
Hello skaller,
Tuesday, June 19, 2007, 8:15:19 PM, you wrote:
are you plan to implement 64-bit windows GHC version?
Why do you need mingw? What's wrong with MSVC++?
really! Simon, how about unregisterised build?
Unregisterised would still need a C compiler capable of generating 64-bit code. Are you talking about using the MS compiler for that? Certainly possible, but I'm not sure why you'd want to do it - you'd end up with much slower code than running the 32-bit compiler. Cheers, Simon
Hello Simon, Wednesday, June 20, 2007, 11:51:34 AM, you wrote:
really! Simon, how about unregisterised build?
Unregisterised would still need a C compiler capable of generating 64-bit code. Are you talking about using the MS compiler for that? Certainly possible, but I'm not sure why you'd want to do it - you'd end up with much slower code than running the 32-bit compiler.
in *my* program all code that is need to be efficient is written in C++ :) generally speaking, people want to use 64-bit code in order to work with much larger data space, overall speed may be better than using 32-bit version with 2gb limit so, if it is a not big problem - afaiu unregisterized build should be easy? - can you please build such version? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, 2007-06-20 at 22:59 +0400, Bulat Ziganshin wrote:
generally speaking, people want to use 64-bit code in order to work with much larger data space, overall speed may be better than using 32-bit version with 2gb limit
With x86_64, 64 bit programs are usually faster than 32 bit ones even for small data, probably because despite the extra stack space etc that is required for double sized pointers, there are also more registers. There may also be a penalty for 32 bit code in other parts of the processing pipeline, eg segmentation (which is not available for 64 bit code). IMHO the main use of 32 bit machines now is embedded applications, for example mobile phones. Desktops are all switching to 64 bit: Amd64 dual core PC-like machines are now very cheap: a friend just bought one for $A500 .. at that kind of price there's no reason to even think about buying a 32 bit desktop box. Portables will follow quickly. Systems like GHC really need to target the major boxes that will be in use in 3 years, not what we have now. I wouldn't drop 32 bit support -- there's LOTS of money in mobile phones, and mass production provides money to pay for more secure software such as use of more advanced languages like Haskell where one is more confident of correctness than an equivalent C program. Still .. the main thrust has to be desktops, because desktops are what developers use, and before a PL can be adopted in embedded systems or servers you need a community of programmers so management knows it can replace those hit by buses... -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
Hello skaller, Thursday, June 21, 2007, 7:06:09 AM, you wrote:
generally speaking, people want to use 64-bit code in order to work with much larger data space, overall speed may be better than using 32-bit version with 2gb limit
With x86_64, 64 bit programs are usually faster than 32 bit ones even for small data, probably because despite the extra stack space etc that is required for double sized pointers, there are also more registers. There may also be a penalty for 32 bit code in other parts of the processing pipeline, eg segmentation (which is not available for 64 bit code).
this small speed increase will be easily outweighted by using non-optimizing (un*register*ized means "non using registers in optimal way") compiler the whole problem is that GHC has very complex compilation strategy which is fine-tuned for every platform fully supported. it mangles asm code produced by C compiler, it uses registers directly, so on. this is so-called registerized build. and without all these optimizations it just generates plain ANSI C code, this is unregizterized build. the last is much simpler to implement - you need to port only libraries/RTS
IMHO the main use of 32 bit machines now is embedded applications, for example mobile phones.
but this doesn't apply to 32-bit code. moreover, you say about computers that are now selled but there are lots of old boxes. and not everyone with 64-bit CPU buys 64-bit OS from my POV, main reason for 64-bitness is using more than 2G of memory, and growed amount of memory in typical desktops was the reason why 64-bit systems now becomes popular. in terms of CPU architecture, x86-64 is still CISC while RISC and EPIC architectures proven their efficiency in last 20 years. doubled amount of registers is very small step in this direction -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw.
Why do you need mingw? What's wrong with MSVC++?
We have talked (extensively) about doing a Windows port using the MS tools instead of mingw. Check the archives of cvs-ghc, search for "windows native". There's no problem in theory, but it's a lot of work. Peter Tanski has done some work in this direction, he should be able to tell you more. I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly "free", and we want to retain the ability to have a completely free distribution with no dependencies. There are people that want a Cygwin port too; personally I think this is heading in the wrong direction, we want to be more "native" on Windows, using the native object format and interoperating directly with the native Windows tools. Cheers, Simon
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly "free", and we want to retain the ability to have a completely free distribution with no dependencies.
I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products. Don't forget -- Windows isn't a free operating system. You're juggling some possible problem with a single source vendor withdrawing supply (possible) against open source products which are late to market (definite :) 64 bit Mingw .. will already be years out of date when it turns up, since MS is focusing on .NET platform. MSVC++ tools already support CLR, assemblies and .NET: even if Mingw supported that .. you'd still need Mono (does it work, really?) for a 'free' platform .. but .NET is redistributable and available on most modern Windows platforms already .. I doubt the Open Source community is as reliable a supplier for the Windows market as Microsoft. It's really a boutique market. Cygwin was a major platform in the past, for running Unix software on Windows. But now we're talking about a Windows *native* version of GHC, there's no "Unix" in it. I see no real reason not to build for the native toolchain .. and plenty of reasons not to bother with others. Hmm .. can't MS be coaxed into supplying some support to the developers? After all, Haskell IS a major lazily evaluated statically typed functional programming language. Why wouldn't MS be interested in bringing GHC on board? They have an Ocaml (called F#) now.. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
skaller wrote:
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly "free", and we want to retain the ability to have a completely free distribution with no dependencies.
I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products.
"The binaries needed by programs built by these tools...", you're referring to the C runtime DLLs? Why does that matter? Note I said "with no dependencies" above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff.
Hmm .. can't MS be coaxed into supplying some support to the developers? After all, Haskell IS a major lazily evaluated statically typed functional programming language. Why wouldn't MS be interested in bringing GHC on board? They have an Ocaml (called F#) now..
MS pays for Ian Lynagh, who works full time on GHC as a contractor. MS puts roughly as much money into GHC as it does into F#, FWIW. Cheers, Simon
Hi
I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products.
"The binaries needed by programs built by these tools...", you're referring to the C runtime DLLs? Why does that matter?
Note I said "with no dependencies" above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff.
I don't compile GHC on Windows, as its kind of annoying to do, and the binaries are usually sufficient for my needs. Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express. Compare this to Cygwin/Mingw where the packaging is frankly awful, and makes my head hurt every time I have to install it. I'm looking forward to having GHC built with Visual Studio, but I can understand why its not a priority - the advantages are relatively minimal. What I keep hoping is that Microsoft will put some serious thought into debugging Haskell - the MS tools for debugging blow away everything else. (I realise a start is being made in GHCi, and am looking forward to the end results!) Thanks Neil
Neil Mitchell wrote:
Hi
I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products.
"The binaries needed by programs built by these tools...", you're referring to the C runtime DLLs? Why does that matter?
Note I said "with no dependencies" above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff.
I don't compile GHC on Windows, as its kind of annoying to do, and the binaries are usually sufficient for my needs. Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express.
Compare this to Cygwin/Mingw where the packaging is frankly awful, and makes my head hurt every time I have to install it.
Not a fair comparison - I'm talking about *users* of GHC, who currently do not have to download anything except GHC itself. With a Windows native port they'd have to also get VS Express and the MASM package separately. GHC *developers* wouldn't be any better off either. You'd still need either Cygwin or MSYS for the build environment. There's no way I'm using MS build tools, ugh. Cheers, Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote:
Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express.
I would have some difficulty, because I would feel obliged to read the license first and decide whether it felt acceptable for me to agree to. That's the same reason I haven't started up iTunes on my MacBook - reading the general Apple-software license was tiring enough! This is one place GNU/Linux/(other Free systems) really shine, even compared to OS X: you don't have to explicitly accept a click-through license the first time you start everything up (iterated for every new installation and computer, and they don't tell you whether it's the same version of the license that you read earlier). (Copyright doesn't require you to click to agree; I've already read the GPL and a few other Free licenses; and I trust the FSF's judgment in what freedoms the other miscellaneous Free licenses grant.) But I guess that doesn't matter to "most" Windows users... even if they're developers of FOSS ... ? Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeUihHgcxvIWYTTURAiSmAJ4yy6SinJgfUKARozwcYuxvSoUgdwCgpZD9 JFI0TddUPvYjGogtgjQnVM8= =FInN -----END PGP SIGNATURE-----
On Wed, 2007-06-20 at 14:42 +0100, Simon Marlow wrote:
"The binaries needed by programs built by these tools...", you're referring to the C runtime DLLs? Why does that matter?
Note I said "with no dependencies" above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff.
So what? Felix requires: (a) C/C++ compiler (b) Python (c) Ocaml you have to download and install these tools on ANY platform, including Ubuntu Linux. gcc isn't installed on a basic system. True, with Debian, this can be automated, so you only have to click on the main package. I need THREE external tools. Is this a pain? YES! [On Windows .. it's a breeze on Ubuntu .. :] Is it too much effort to ask, for someone to use a major advanced programming language like Haskell? Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up.
MS pays for Ian Lynagh, who works full time on GHC as a contractor. MS puts roughly as much money into GHC as it does into F#, FWIW.
I'm happy to hear that! Now let me turn the argument around. Mingw is a minor bit player. The MS toolchain is the main toolchain to support. C++ can't run on Mingw for example (MS and gcc C++ are incompatible). GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena. Commercial programming is in a bad way! It NEEDS stuff like Haskell available. BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :) -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
skaller wrote:
GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena.
Commercial programming is in a bad way! It NEEDS stuff like Haskell available.
BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :)
This is a fine point, and probably the biggest reason for doing a Windows native port. I'd like to see it happen, but we need help! Cheers, Simon
I would be more than happy to help. Maybe we need to get a sub-team together and start plowing through this mine-field? -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Marlow Sent: Wednesday, June 20, 2007 10:29 AM To: skaller Cc: glasgow-haskell-users@haskell.org; Bulat Ziganshin Subject: Re: 64-bit windows version? skaller wrote:
GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena.
Commercial programming is in a bad way! It NEEDS stuff like Haskell available.
BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :)
This is a fine point, and probably the biggest reason for doing a Windows native port. I'd like to see it happen, but we need help! Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. *************************************************************************
| > BTW: I don't really like Windows .. but I want to see Haskell | > succeed. Trying to do Haskell on Windows without MSVC++ toolchain | > is like trying to work on Linux without binutils... :) | | This is a fine point, and probably the biggest reason for doing a | Windows native | port. I'd like to see it happen, but we need help! | I would be more than happy to help. Maybe we need to get a sub-team | together and start plowing through this mine-field? That'd be great! A good way to start might be to start GHC-Trac Wiki page, identify who wants to be involved, and sketch the challenges. thanks! Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 skaller wrote:
(MS and gcc C++ are incompatible).
is this still true? GCC has been standardizing its C++ ABI for a while, and I think there actually weren't any ABI changes noted between 4.1 and 4.2 for most platforms (I don't know if MS C++ is compatible with that common ABI though). I could be confused here though.
BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :)
yes, binutils written in Haskell! Will never happen! :)) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeUpvHgcxvIWYTTURAimNAKClTAkuRU3pr/ASsfSZdGiYoNLsmwCgo4G2 Oh/mK9MQ2vcRLAeaT4bOsdo= =0nHh -----END PGP SIGNATURE-----
On Wed, 2007-06-20 at 11:40 -0400, Isaac Dupree wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
skaller wrote:
(MS and gcc C++ are incompatible).
is this still true? GCC has been standardizing its C++ ABI for a while, and I think there actually weren't any ABI changes noted between 4.1 and 4.2 for most platforms (I don't know if MS C++ is compatible with that common ABI though). I could be confused here though.
I believe so, but I could be wrong. MSVC++ uses different name mangling as well as function call/register usage conventions on AMD64 I think, but I'm not sure since I only have Cygwin g++, which is a very old compiler now (3.3 or something?) As I understand it, gcc is highly configurable wrt to the back end, still, stuff like C++ exception handling etc is quite hard to parametrise. It would be very cool if g++ could replace MSVC++, but I wouldn't hold your breath. MS now uses 'assemblies' for dynamic linkage, which is an advanced version of the common Unix *.so.1.2+ symlinks hackery, so just as g++ can create compatible C++ dlls it is going to be out of date on the dynamic loading method .. by the time it catches up on that, most MS applications will probably be .NET based and binaries will be reserved for privileged users and device drivers (I'm not kidding on that either -- MS does have a few security problems and .NET is probably the vehicle they'll use to solve them). The problem for software like GHC is that it can't afford to trail behind development of Open Source support technology like C compilers. The lag is too great: to be successful it needs to be on the bleeding edge .. after all from a *programming language* viewpoint it is bleeding edge software. Ocaml has jumped onto the bleeding edge with F#... ok, they're not the same exactly, and the fork is unpleasant, but F# is already a .NET language, so MS developers in a position to take some risks might have a go with it. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
On Thu, Jun 21, 2007 at 12:35:15AM +1000, skaller wrote:
Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and MSYS. You download it, run it, and click Next a few times. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org
Hi
Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and MSYS. You download it, run it, and click Next a few times.
Its far from that easy! Its loads of steps, and figuring out what to download is quite challenging on its own. Thanks Neil
Neil Mitchell wrote:
Hi
Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and MSYS. You download it, run it, and click Next a few times.
Its far from that easy! Its loads of steps, and figuring out what to download is quite challenging on its own.
Thanks
Neil
I agree with Neil. I had a non trivial problem understanding what parts of which versions of Mingw and/or MSYS I should download to get ghc compiling on windows. I had to try at least three times before I setup something that works. And I assert that I am a competent person. I think their web site seriously under-explains things from an outsider's point of view. But the user base is made up of programmers, so they obviously are not under pressure to make a clearer site.
Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and MSYS. You download it, run it, and click Next a few times.
Its far from that easy! Its loads of steps, and figuring out what to download is quite challenging on its own.
I had a non trivial problem understanding what parts of which versions of Mingw and/or MSYS I should download to get ghc compiling on windows. I had to try at least three times before I setup something that works. And I assert that I am a competent person. I think their web site seriously under-explains things from an outsider's point of view. But the user base is made up of programmers, so they obviously are not under pressure to make a clearer site.
so it is probably easier to install that to figure out what to install? yes, i remember the download site being rather confusing in its variety of packages and versions on offer, the all-in-one package being much older than the individual packages, because one is meant to install the all-in-one, then update it by installing the more frequently updated individual packages on top of that. and then were stable and unstable versions of those individual packages. or something like that.. personally, i use the cygwin environment, so only needed to install mingw gcc&co. but it would be nice if one of you who have figured out what and how to install a minimal mingw/msys sufficient for ghc builds could write it up in a detailed log, similar to the existing one for mingw/cygwin: http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogus... that would help others in the future, and they can send updates to the log when the details change. if you don't remember all the details, just write up what you remember, and let others fill in when they are actually doing an install. [simon: i recall sending a minor update to the cygwin log, including where to get darcs, and changing to the current mailing list setup; has that disappeared?] claus
On Sun, Jun 24, 2007 at 12:45:33PM +0100, Claus Reinke wrote:
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogus...
that would help others in the future, and they can send updates to the log when the details change. if you don't remember all the details, just write up what you remember, and let others fill in when they are actually doing an install.
Instead of grabbing Cygwin, grab two other files along with MinGW installer. Presume you are at the SourceForge download page for MinGW (yes, I know SF is annoying): Under Current, unfold the full listing of packages: Unfold MinGW, MSYS, and MSYS Developer Tool Kit. Download the latest of + MinGW-*.exe, + MSYS-*.exe, + msysDTK-*.exe There aren't many .exe files, so it should be easy to pick them out. Install MinGW, then MSYS, then msysDTK. They are all ordinary Windows installers (NSIS I think). This installs your system in the "approved" manner, so it should be easy to later grab individual updates and simply unpack them into here. That should take care of your non-Haskell related packages. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org
On Sun, 2007-06-24 at 13:10 -0400, Matthew Danish wrote:
Unfold MinGW, MSYS, and MSYS Developer Tool Kit.
Hmm .. well I'm not sure if this is still correct, but Mingw, being a Windows program, has 255 character limit on command line .. which makes it useless for building anything complex. Ocaml had this problem: the MinGW version of Ocaml has to be built using Cygwin, with gcc using the -mnocygwin option. The thing is .. Cygwin, despite being rather large, is much easier to install than MSYS because of the package manager. Also there are many emulations of Unix programs for Windows, located at: http://gnuwin32.sourceforge.net/ which are also fairly easy to install and work from the CMD.EXE command prompt. The problem with building on Windows is that many scripts assume bash, and it just doesn't work 'right' outside a well configured Unix environment. Cygwin does this quite well .. MSYS etc doesn't. I'm not intending to knock MSYS .. but I wouldn't rely on it for building complex projects 'transparently' .. Cygwin has enough problems doing that, and it's quite a sophisticated environment. The thing is .. Windows *.bat files, though a bit clumsy, work better than trying to get a bash emulation .. but really, designed-to-be-portable code written in Python, Perl, Scheme, or even Haskell is better .. because it eliminates uncertainty and gives you full control of how build actions are implemented on each platform. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
participants (11)
-
Bulat Ziganshin -
Chris Kuklewicz -
Claus Reinke -
Dinko Tenev -
Green Bryan - bgreen -
Isaac Dupree -
Matthew Danish -
Neil Mitchell -
Simon Marlow -
Simon Peyton-Jones -
skaller