Menu
▾
▴
mingw-users
|
From: Josh K. <jk...@le...> - 2010-08-25 00:18:27
|
I am trying to get MinGW to recognize the -Wfatal-errors the codeblocks IDE uses to make the compiler stop on the first error. However, the latest version 5.1.6 of MinGW gives this error: cc1.exe: error: unrecognized command line option "-Wfatal-errors" Has the name of this tag changed? Is it no longer supported? If so, what was the last version of MinGW that supported this option? Thanks. Best Regards, Josh Klint |
|
From: Greg C. <gch...@sb...> - 2010-08-25 00:41:52
|
On 2010-08-24 23:51Z, Josh Klint wrote: > I am trying to get MinGW to recognize the -Wfatal-errors the codeblocks IDE > uses to make the compiler stop on the first error. However, the latest > version 5.1.6 of MinGW gives this error: > > cc1.exe: error: unrecognized command line option "-Wfatal-errors" That option is still valid with the latest gcc: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html#Warning-Options This seems to be a codeblocks problem. Here's a solution in French: http://www.siteduzero.com/forum-83-298807-p1-compilation-cb.html and here's an English translation: http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.siteduzero.com%2Fforum-83-298807-p1-compilation-cb.html&sl=fr&tl=en |
|
From: Josh K. <jk...@le...> - 2010-08-25 02:02:44
|
The only advice given in that forum thread is to disable the option. I want very much for the compiler to stop on the first error. This is the output from codeblocks: -------------- Build: Release Win32 in LE3 --------------- Compiling: ..\LuaJIT-1.1.6\src\lapi.c cc1.exe: error: unrecognized command line option "-Wfatal-errors" Process terminated with status 1 (0 minutes, 0 seconds) 0 errors, 0 warnings Best Regards, Josh Klint -----Original Message----- From: Greg Chicares [mailto:gch...@sb...] Sent: Tuesday, August 24, 2010 5:42 PM To: MinGW Users List Cc: Josh Klint Subject: Re: [Mingw-users] Stop on first error? On 2010-08-24 23:51Z, Josh Klint wrote: > I am trying to get MinGW to recognize the -Wfatal-errors the codeblocks IDE > uses to make the compiler stop on the first error. However, the latest > version 5.1.6 of MinGW gives this error: > > cc1.exe: error: unrecognized command line option "-Wfatal-errors" That option is still valid with the latest gcc: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html#Warning-Opt ions This seems to be a codeblocks problem. Here's a solution in French: http://www.siteduzero.com/forum-83-298807-p1-compilation-cb.html and here's an English translation: http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&e otf=1&u=http%3A%2F%2Fwww.siteduzero.com%2Fforum-83-298807-p1-compilation-cb. html&sl=fr&tl=en |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 02:03:21
|
Greg Chicares wrote: > That option is still valid with the latest gcc: > http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html#Warning-Options Yeah, wrong page. It's valid for the latest version of gcc indeed, but the mingw 5.1.6 does not provide the latest gcc, it provides some gcc 3 version. I don't feel like installing it to see which one exactly, but it doesn't matter really. Josh Klint wrote: > I am trying to get MinGW to recognize the -Wfatal-errors the codeblocks IDE > uses to make the compiler stop on the first error. However, the latest > version 5.1.6 of MinGW gives this error: > > cc1.exe: error: unrecognized command line option "-Wfatal-errors" As seen here, there is no such an option in gcc 3: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html#Warning-Options MinGW-5.1.6 is the latest installer and meant to be the last one ever, yet it is quite old. The intention is being replaced by mingw-get. Unfortunately, mingw-get isn't done yet and as such, only gets you gcc 3 as well. This means the only official way to install gcc 4 is to do a manual install. There are unofficial ways, but they are considered off topic here, so I can only tell you to search for them yourself. Other projects, like TDM and mingw64 do offer recent installers, so they could be an alternative. To the mingw "crew": This is the third time in a very short time I have had to tell this story. It seems to me this message should be (more obviously) on the site. On top of that, I would like to urge you to do the following: provide a method to install a recent version of gcc (other than manual). Perhaps this means that mingw-get should be able to install gcc 4 real soon, perhaps this means that you should adapt some temporary install method as "official" until mingw-get is able to install gcc 4. I am afraid you are shooting yourself in the foot and losing users by not doing so. I don't like to have to mention other mingw projects in order to be able to mention recent mingw installers. Jasper |
|
From: Peter R. <p.r...@sh...> - 2010-08-25 09:11:26
|
... > This is the third time in a very short time I have had to tell this > story. It seems to me this message should be (more obviously) on the > site. On top of that, I would like to urge you to do the following: > provide a method to install a recent version of gcc (other than > manual). Perhaps this means that mingw-get should be able to install > gcc 4 real soon, perhaps this means that you should adapt some > temporary install method as "official" until mingw-get is able to > install gcc 4. I am afraid you are shooting yourself in the foot and > losing users by not doing so. I don't like to have to mention other > mingw projects in order to be able to mention recent mingw installers. Unfortunately, have to say I agree! The first item you come to on the SF downloads page is "Automated MinGW Installer" which one would reasonably assume to be the THE installer. The user comments on SF mostly run along the lines of "great toolchain - nightmare install". The 5.1.6 installer is still getting ~2000 downloads a day. I was planning to have a look at the code for the old Nullsoft installer to see how easy this would be to update, if only for my own use, but haven't got far due to pressures of work. Might an update of the installer be a good short-term fix until mingw-get is ready (as a GUI)? Peter |
|
From: Keith M. <kei...@us...> - 2010-08-25 10:05:23
|
On 25/08/2010, Peter Rockett <p.r...@sh...> wrote: > ... >> This is the third time in a very short time I have had to tell this >> story. It seems to me this message should be (more obviously) on the >> site. Isn't http://mingw.org/wiki/Getting_Started sufficiently obvious? >> On top of that, I would like to urge you to do the following: >> provide a method to install a recent version of gcc (other than >> manual). Perhaps this means that mingw-get should be able to install >> gcc 4 real soon, All that is missing is a fragment -- okay, it's a fairly substantial fragment -- of XML, to describe the package dependencies. >> perhaps this means that you should adapt some >> temporary install method as "official" until mingw-get is able to >> install gcc 4. I am afraid you are shooting yourself in the foot and >> losing users by not doing so. I don't like to have to mention other >> mingw projects in order to be able to mention recent mingw installers. > > Unfortunately, have to say I agree! The first item you come to on the SF > downloads page is "Automated MinGW Installer" which one would reasonably > assume to be the THE installer. And this is now mingw-get; MinGW-5.1.6 is dead, and buried. > The user comments on SF mostly run along > the lines of "great toolchain - nightmare install". The 5.1.6 installer > is still getting ~2000 downloads a day. > > I was planning to have a look at the code for the old Nullsoft installer > to see how easy this would be to update, if only for my own use, but > haven't got far due to pressures of work. Right. That's exactly why mingw-get isn't ready yet -- at this moment in the development cycle, there are only two developers who are actively contributing to the effort of generating the needed XML description files; both of us have constraints on *our* time. > Might an update of the > installer be a good short-term fix until mingw-get is ready[?] If you want to contribute one, be my guest; I will not be wasting even one more second on development of an NSIS based solution. Your time would likely be better spent on helping out with the mingw-get XML. > (as a GUI)? So, you think it necessary to provide a GUI installer for a product which is designated for CLI use? If a user can't type (at a CLI prompt): mingw-get install foo how do you expect them to manage: gcc -o foo.exe foo.c (or the more complex sequence of commands typical of a real project)? IMO, a functional CLI capable installer is where the current focus needs to be; a GUI wrapper can come later. -- Regards, Keith. |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 10:56:35
|
Keith Marshall wrote: > Isn't http://mingw.org/wiki/Getting_Started sufficiently obvious? Apparently not. (though in combination with burying mingw-5.1.6 it might be) > If you want to contribute one, be my guest; I will not be wasting even > one more second on development of an NSIS based solution. How about not continuing the old type of installer, but simply having an installer that contains an archive containing the results of a manual install which it extracts? As a temporary solution it wouldn't need an option to download it all first, nor would it have to be updated every time a package is updated, nor would it have to have options what to install and what not to install. I don't believe this should take more than one or two hours (perhaps with NSIS, but there are other options). It needn't be a fully functional installer, just something that works well enough for now. (Note that I have never done a manual install yet, so I would have to put some more time into it (though I don't think it would be a problem, a manual install doesn't seem all that complicated; the main problem is there only being a step by step guide, not just a simple "you need to extract these packages to a directory"-type of guide). On top of that, this would have to be done by someone who has an installation already - so it can't be done for one's own gain, meaning it won't be done until it is promised it will be "supported" beforehand) > Your time > would likely be better spent on helping out with the mingw-get XML. If an installer can get done in less time than it would take to get mingw-get to work with gcc 4, then I would say it isn't better spend on mingw-get. With a statistic like 2000 users a day previously downloading mingw-5.1.6, I think one will currently lose at least a dozen users every hour who give up on mingw(.org) (some of whom gave up before, some of whom downloaded the old installer previously), so every hour saved is valuable. > So, you think it necessary to provide a GUI installer for a product which > is designated for CLI use? If a user can't type (at a CLI prompt): > > mingw-get install foo > > how do you expect them to manage: > > gcc -o foo.exe foo.c Through an IDE? Nevertheless, it is indeed most important to have some installer working first, not necessary a GUI installer (though I would like to second a suggestion made elsewhere on this list: having a GUI installer that installs mingw-get and then runs it with some default parameters to bridge the gap that exists from the moment the mingw-get CLI is completed to the moment the mingw-get GUI is). Jasper |
|
From: Josh K. <jk...@le...> - 2010-08-25 14:36:26
|
I agree 100%. Don't let some technocrat tell you otherwise. Best Regards, Josh Klint If an installer can get done in less time than it would take to get mingw-get to work with gcc 4, then I would say it isn't better spend on mingw-get. With a statistic like 2000 users a day previously downloading mingw-5.1.6, I think one will currently lose at least a dozen users every hour who give up on mingw(.org) (some of whom gave up before, some of whom downloaded the old installer previously), so every hour saved is valuable. |
|
From: Peter R. <p.r...@sh...> - 2010-08-25 11:31:10
|
> So, you think it necessary to provide a GUI installer for a product which > is designated for CLI use? If a user can't type (at a CLI prompt): > > mingw-get install foo > > how do you expect them to manage: > > gcc -o foo.exe foo.c > > (or the more complex sequence of commands typical of a real project)? 1) I can honestly say in many years of using various C(++) compilers, I have never once invoked a compiler from the CLI! (Apart from indirectly via make files.) I have only ever used an IDE for my own projects. Everybody I know uses an IDE. I suppose there must be command-line warriors left but they're surely a dying breed. 2) Typing mingw-get install foo once isn't the problem. It's the fact that you have to type mingw-get install umpteen times (for gmp, mpfr, mpi, etc.) to get the toolchain working. If you want ada or fortran there's other stuff to type. Of course this could all be usefully automated in batch files, one for the base C compiler, one for C++, another for C and fortran, etc., etc. That gives a 1-from-N choice where N is a large number. A GUI is an obvious way to solve that 1-from-N problem... |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 11:42:37
|
Peter Rockett wrote: > I suppose there must be command-line > warriors left but they're surely a dying breed. I think that's just plain untrue. Luckily, it's quite irrelevant to your (our) point. Jasper |
|
From: Peter R. <p.r...@sh...> - 2010-08-25 11:50:55
|
>> I suppose there must be command-line >> warriors left but they're surely a dying breed. > I think that's just plain untrue. Luckily, it's quite irrelevant to > your (our) point. > OK. Happy to stand corrected. But I don't know any... Peter |
|
From: Earnie <ea...@us...> - 2010-08-25 11:54:31
|
Peter Rockett wrote: > >> So, you think it necessary to provide a GUI installer for a product which >> is designated for CLI use? If a user can't type (at a CLI prompt): >> >> mingw-get install foo >> >> how do you expect them to manage: >> >> gcc -o foo.exe foo.c >> >> (or the more complex sequence of commands typical of a real project)? > > 1) I can honestly say in many years of using various C(++) compilers, I > have never once invoked a compiler from the CLI! (Apart from indirectly > via make files.) I have only ever used an IDE for my own projects. > Everybody I know uses an IDE. I suppose there must be command-line > warriors left but they're surely a dying breed. > I hate IDE as much or more than you dislike CLI. For one thing the IDE hides things that you need to know. You need to think about that program you're creating and using an IDE hides much of the interaction of the libraries. But then I am one of the dying breed who started IT life with 32K words of memory to execute a program in. I had to write a file for the linker to code in what object files to have in memory to satisfy the dependencies for other object files being used. Now we need 4G memory just to run the OS and do something productive. I blame the lazy ones who use the IDE for this creep of memory usage. > 2) Typing mingw-get install foo once isn't the problem. It's the fact > that you have to type mingw-get install umpteen times (for gmp, mpfr, > mpi, etc.) to get the toolchain working. If you want ada or fortran > there's other stuff to type. Of course this could all be usefully > automated in batch files, one for the base C compiler, one for C++, > another for C and fortran, etc., etc. That gives a 1-from-N choice > where N is a large number. A GUI is an obvious way to solve that > 1-from-N problem... > Actually, you just install the toolchain you want and the dependencies will be installed for you. So the meta data for mingw-get could have a "toolchain" called Fortran and the meta data for the "toolchain" would know which packages were needed to be installed. I don't see that as too much of a hardship. The problem becomes the creation of the "toolchain" meta data just like when I was telling the linker what objects to have in my 64K bytes of memory. Someone has to type rather than clicking or dragging and dropping in a GUI. Anecdote: A GUI is for those without a CLUI. -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 12:05:49
|
Earnie wrote: > Anecdote: A GUI is for those without a CLUI. Right. Now that the irrelevant calling of names* is over, can we get to the point? There are people that require a GUI, so are we ready to lose them or are we providing them with one? (at the very least until mingw-get is done) Jasper *alright it was mild, but it's the best term I could come up with |
|
From: Earnie <ea...@us...> - 2010-08-25 12:42:32
|
Jasper Horn wrote: > Earnie wrote: >> Anecdote: A GUI is for those without a CLUI. > > Right. > > Now that the irrelevant calling of names* is over, can we get to the > point? There are people that require a GUI, so are we ready to lose > them or are we providing them with one? (at the very least until > mingw-get is done) > If you want to code a GUI to drive the command line mingw-get and maintain it when can arrange for that. Keith has plans in the far distant future for a GUI to drive mingw-get but if someone wants to code it now, go for it. We'll be happy to arrange access to the VCS. -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 12:59:02
|
Earnie wrote: > If you want to code a GUI to drive the command line mingw-get and > maintain it when can arrange for that. Keith has plans in the far > distant future for a GUI to drive mingw-get but if someone wants to code > it now, go for it. We'll be happy to arrange access to the VCS. Maybe I'll help on that later, but I think the priority right now should be to get a supported installer that installs a recent version of gcc. (as such, if I do, it probably won't be before it can install gcc 4) My intention was to steer the conversation away from "you should use GUIs" vs "you should use GUIs" as it really doesn't matter - if you are losing users over not having a proper installer (and yes, I think that includes having a GUI to some extent, but includes having an installer that installs gcc 4 to a much larger extent) you should either state that you don't care or you should provide a proper installer. Jasper |
|
From: Earnie <ea...@us...> - 2010-08-25 13:22:04
|
Jasper Horn wrote: > > My intention was to steer the conversation away from "you should use > GUIs" vs "you should use GUIs" as it really doesn't matter - if you > are losing users over not having a proper installer (and yes, I think > that includes having a GUI to some extent, but includes having an > installer that installs gcc 4 to a much larger extent) you should > either state that you don't care or you should provide a proper > installer. > Your concern for loss of users is honorable. But are we loosing them over the lack of an installer of GCC 4 or the lack of 64 bit support? We can update the mingw.ini file that controls the current installer but we need someone to maintain it. Maintaining it would require watching for updates to packages, modifying the mingw.ini file and submitting the changes to CVS. -- Earnie -- http://www.for-my-kids.com |
|
From: Peter R. <p.r...@sh...> - 2010-08-25 12:13:23
|
> Anecdote: A GUI is for those without a CLUI. :-) Earnie, I'm curious what an IDE "hides" that a CLI invocation tells you? |
|
From: Earnie <ea...@us...> - 2010-08-25 12:32:30
|
Peter Rockett wrote: > >> Anecdote: A GUI is for those without a CLUI. > :-) > > Earnie, I'm curious what an IDE "hides" that a CLI invocation tells you? I suppose nothing. The CLI invocation would eventually end up in a Makefile for me to never think about again just like the IDE. I'm happy you smiled at the poor humor. -- Earnie -- http://www.for-my-kids.com |
|
From: Tor L. <tm...@ik...> - 2010-08-25 12:36:22
|
> Earnie, I'm curious what an IDE "hides" that a CLI invocation tells you? What commands are invoked, exactly. What options are passed to the compiler. Etc. Stuff you can then cross-reference with the gcc manual page (in the case of gcc). --tml |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 12:44:35
|
Tor Lillqvist wrote: >> Earnie, I'm curious what an IDE "hides" that a CLI invocation tells you? > > What commands are invoked, exactly. What options are passed to the > compiler. Etc. Stuff you can then cross-reference with the gcc manual > page (in the case of gcc). Not all IDEs do... Jasper |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 13:42:25
|
Earnie wrote: > Your concern for loss of users is honorable. But are we loosing them > over the lack of an installer of GCC 4 or the lack of 64 bit support? Well, I started a conversation about the other possibility not too long ago, and unfortunately it turned out that taking steps to work together with mingw64 more closely were generally regarded as a lot of effort (and changes in general some people were not ready to make) and too many people did not see an eventual merger of the projects happening (which, in my eyes should be the ultimate goal, even if it takes several years more of cooperation, before it will be possible). Either way, I have a feeling that the installer is a bigger problem the 64 bit support, but I may be wrong about that. > We can update the mingw.ini file that controls the current installer but > we need someone to maintain it. Maintaining it would require watching > for updates to packages, modifying the mingw.ini file and submitting the > changes to CVS. I am currently looking updating it. I am not making any promises about maintaining it yet, though (even providing gcc 4.5.0 while 4.5.1 is out is better than providing only gcc 3 installations in my opinion). Jasper |
|
From: Earnie <ea...@us...> - 2010-08-25 15:31:10
|
Jasper Horn wrote: > Earnie wrote: > >> Your concern for loss of users is honorable. But are we loosing them >> over the lack of an installer of GCC 4 or the lack of 64 bit support? > > Well, I started a conversation about the other possibility not too > long ago, and unfortunately it turned out that taking steps to work > together with mingw64 more closely were generally regarded as a lot of > effort (and changes in general some people were not ready to make) and > too many people did not see an eventual merger of the projects > happening (which, in my eyes should be the ultimate goal, even if it > takes several years more of cooperation, before it will be possible). > > Either way, I have a feeling that the installer is a bigger problem > the 64 bit support, but I may be wrong about that. > How many years has 64 bit Windows been available? We are that many years behind. The mingw-w64 project is providing both a backward compatible Win32 as well as a Win64 versions of MinGW with multilib support they are miles ahead of us. I'm all for a cooperative spirit and what they have going is good. The fork happened because the originator needed to move quicker than we were allowing him because of constraints from his employer. Not a bad thing but the bigger problem was a communication gap. I am monitoring the users list and participating in conversations their. Especially in regard to the use of MSYS. >> We can update the mingw.ini file that controls the current installer but >> we need someone to maintain it. Maintaining it would require watching >> for updates to packages, modifying the mingw.ini file and submitting the >> changes to CVS. > > I am currently looking updating it. I am not making any promises about > maintaining it yet, though (even providing gcc 4.5.0 while 4.5.1 is > out is better than providing only gcc 3 installations in my opinion). > It will be good if you can make it happen. -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-08-25 13:57:30
|
KHMan wrote: > Manpower is always the limitation, why do people keep "wanting > this, wanting that", "it must be done this way, why isn't people > jumping up and doing it"? -- please contribute to the effort so > that the community can move it along. I don't want it personally, I want it for the mingw project. Actually, me saying that is a form of contributing; it may not be much, but it's what I have right now... > Talk along the lines of "losing users over not having a proper > installer" or "should provide a proper installer" seems like > really a selfish and shallow attitude. We all know there are 1001 > things that can be done, no need for a genius to point out and > repeat things ad nauseam. The shallow attitude is saying that, while when someone makes an installer, the reaction is that they can't talk about it on this mailing list... > The project is not selling a product, nor is it giving out a free > product in order to capture market share. This is a community, the > developers are not obliged to deal with users like they are customers. That's true. However, a project with only developers isn't of much use either. Note also that I have also said that if you don't care about losing those users, that should just be made clear. If the mingw "staff" does that, I will not continue on this subject - in that case your point is clear. > Start thinking about how you can move things along in a > constructive way. So please consider contributing effort or > contributing greenbacks. I'm sorry you feel is not a constructive way. If you would rather not have me not start a discussion like this one, just tell me so. I do, however, consider this discussion rather valuable. Jasper |
|
From: KHMan <kei...@gm...> - 2010-08-25 15:01:12
|
On 8/25/2010 9:57 PM, Jasper Horn wrote: > KHMan wrote: > [snip snip] >> Talk along the lines of "losing users over not having a proper >> installer" or "should provide a proper installer" seems like >> really a selfish and shallow attitude. We all know there are 1001 >> things that can be done, no need for a genius to point out and >> repeat things ad nauseam. > > The shallow attitude is saying that, while when someone makes an > installer, the reaction is that they can't talk about it on this > mailing list... FWIW, Andy Koppe's mintty is moving along nicely, so it's not like there is a brick wall. Any out-of-the-blue contributor must be prepared to be rejected out of hand. I think that's reasonable to expect. Any contributed code is going to have to be maintained for the very long term, so I side with the maintainers. Those unhappy can try to maintain a project steadily for 10 years, answer all those user queries, and see if they are up to it. No installer is going to please everyone -- there are many habitual ways of doing things -- e.g. I like "unzip and run, if not delete the whole directory" myself. The upcoming installer seems reasonable to me, and since I'm not paying for it, I can make a reasonable adjustment of habit -- just keep some notes. It's not perfect. Or, it will be perfect for some people and not for others. But something else will be perfect for a different group of people. For everyone to be pleased -- that is impossible. Given the culture differences, people with CLI or Unix experience is likely to be more pleased. Given the heritage of gcc, I think MinGW is right to deal with tools and a minimum of GUI. The demands of GUI and IDE (and there will be tons of newbies) means that those strongly in favour of such things should try to distribute their own packaged version -- and try doing that for 10 years. >[snip] >> Start thinking about how you can move things along in a >> constructive way. So please consider contributing effort or >> contributing greenbacks. > > I'm sorry you feel is not a constructive way. If you would rather not > have me not start a discussion like this one, just tell me so. I do, > however, consider this discussion rather valuable. I've been seeing "want this, want that" or "do this, do that" postings since forever. Too many people is treating MinGW like a product and wishing for better "customer service". Remember that MinGW is always high on the SF popularity list. Put it another way, here's an example: Discussions about terminal programs regularly erupt and have been so for years, but in the end, someone working steadily and quietly is likely going to deliver to us users a more modern terminal program. Talk is fine, but remember, ultimately it is just talk. Unless there is time and manpower, there is no movement. There is no magic wand that can help with this bottleneck. Discussions, yes, but users should not expect that those with manpower are obliged to bend in your direction. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia |
|
From: Geert D. <gee...@ho...> - 2010-08-25 11:53:01
|
> Date: Wed, 25 Aug 2010 11:05:16 +0100 > From: kei...@us... > To: min...@li... > Subject: Re: [Mingw-users] Stop on first error? > > Isn't http://mingw.org/wiki/Getting_Started sufficiently obvious? > NO, the getting started isn't sufficient. I went through the manual install recently and it is a BIG PITA. The stuff you need seems scattered all over the damn place. For people just starting out in this field it just feels like I was doing it wrong or something (but apparently not! back to the 80s). Detailed information about WHAT i'm installing isn't easily accessible, especially for people without any experience. So I end up with a lot of questions and the answer to them doesn't seem trivial (not even with google, or reading the webpage top to bottom) Also, some of the people running this board are so hautain that I wouldn't even want to ask any questions here. Anyway, i got it all to work, i don't really care about Mingw, as long as it compiles c++ code on my windows box i'm happy. Carry on. |
