User forums > General (but related to Code::Blocks)
Changing MinGW compiler, which ships with C::B
eXpl0it3r:
--- Quote from: stahta01 on August 09, 2013, 03:49:38 pm ---Its easy to use CB with a different MinGW Compiler; it just sounds like you are too lazy to support your users in doing that.
--- End quote ---
I know and I'm never using the TDM builds for my projects.
The problem is, even though there's a good tutorial that describes everything, people just don't read and don't bother with using something else, so they use the default one. This is always gonna happen, regardless of what anyone does, thus I'm trying to show why the current default compiler is flawed and should be replaced.
I've 6 different MinGW compilers installed and build my Nightly Builds for all of them (+ 4x Visual Studio), but the TDM builds are the only ones, where I've to run a special script to patch the source to make it work and since the biggest population is using the TDM compiler, I can't just drop it.
--- Quote from: oBFusCATed on August 09, 2013, 03:51:32 pm ---I suppose you know this won't happen, 100% guaranteed :)
And you wont have to wait for two years:)
--- End quote ---
Well just think about it for the next release then.
--- Quote from: oBFusCATed on August 09, 2013, 03:51:32 pm ---BTW: C::B ships a compiler just for a convenience for the novice users. It is just that and there will be always people that would prefer one over the other version, or the third one.
--- End quote ---
Yes of course, but it's not something to put a side that easily. Think about why Google pays Firefox a huge amount of money, so that they keep Google as default search engine and it works. As we've seen in the "discussion" above, people tend to go the way of least resistance and when you offer such a way, you'll also have to think about what you include and how it will affect the user base.
IMHO you can't just go and decline all the request with "You can also use other compilers.", when the default compiler Code::Blocks ships with is flawed.
huzhongshan:
I like TDM-gcc .
If you want to use another mingw , just delete directory Mingw and install Mingw(your version ) in that directory.
eXpl0it3r:
--- Quote from: huzhongshan on August 10, 2013, 12:54:38 am ---I like TDM-gcc .
If you want to use another mingw , just delete directory Mingw and install Mingw(your version ) in that directory.
--- End quote ---
Please read the posts above why this should not be a viable option. ;)
TDragon:
Hi eXpl0it3r,
I think the conflict lies in your expectation that TDM-GCC will conform to some standard form of behavior with respect to the command line. The way I see it, once I start patching GCC to behave differently, it becomes a different compiler and should be treated as such. You can't use the same command line flags to compile a program with MSVC that you use with GCC. If you have a program that compiles with GCC, and you want to port it to MSVC, you will have to make a careful examination of the differences between the two. The same goes for vanilla GCC and TDM-GCC. A user of vanilla GCC switching to TDM-GCC needs to be aware of the differences -- they are few, extremely important, and hopefully well-documented in the TDM-GCC README.
In the case of the static-by-default change, I carefully considered my options in the implementation and decided to have TDM-GCC reject -static-lib*** with an error precisely because this is safer than making it a no-op. Licensing concerns with the GPL (and associated exception clauses) make dynamic linking of libgcc and libstdc++ extremely dangerous to the casual user, so I want TDM-GCC to error out when the user assumes vanilla GCC behavior. This isn't an appropriate time or place for me to go into detail on the legal reasons behind this, so I hope you'll take my word for it as someone who has paid close attention to the discussions of this on the GCC and mingw-users mailing lists.
This is intended as a defense of my design choices with TDM-GCC, rather than of TDM-GCC's inclusion with Code::Blocks. I use Code::Blocks as my primary IDE in my software development work, and I'm very glad that TDM-GCC integrates so well with C::B. There are certainly valid reasons both in support of bundling it (such as Windows-friendliness) and against it (such as my struggle to build GCC 4.8 ), but as I'm not a C::B dev I'll simply leave it to those who are to make an informed decision about its suitability for inclusion as the default compiler.
In order to keep the conversation constructive and focused on Code::Blocks, this will be my only contribution to the thread.
Thanks,
John E. / TDM
eXpl0it3r:
--- Quote from: TDragon on August 10, 2013, 07:47:49 pm ---I think the conflict lies in your expectation that TDM-GCC will conform to some standard form of behavior with respect to the command line. The way I see it, once I start patching GCC to behave differently, it becomes a different compiler and should be treated as such. You can't use the same command line flags to compile a program with MSVC that you use with GCC. If you have a program that compiles with GCC, and you want to port it to MSVC, you will have to make a careful examination of the differences between the two. The same goes for vanilla GCC and TDM-GCC. A user of vanilla GCC switching to TDM-GCC needs to be aware of the differences -- they are few, extremely important, and hopefully well-documented in the TDM-GCC README.
--- End quote ---
While I somewhat agree, I still have to disagree. Although in theory you can look at TDM-GCC as it's "own" compiler, there's no way to actually test this. No third party application does have options to differentiate TDM from GCC, which is also where I have issues with SFML, because CMake doesn't know the difference between some custom GCC compiler and a normal behaving GCC compiler. While on the other hand, it supports all kind of different versions of MSVC and is able to create one NMake file, that will compile with all MSVC regardless of the version, as long as the environment variable are setup correctly.
So if we're not were to go and declare TDM-GCC it's own compiler version, it seems in my option that the website of TDM-GCC should make it clear on the front page, that the compiler should not be looked at as a normal GCC compiler. You maybe even want to drop the GCC, because GCC as describe by the official website:
--- Quote from: GCC GNU ---The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). GCC was originally written as the compiler for the GNU operating system.
--- End quote ---
GCC represents front ends for C++, but by changing that front end to your own needs/ides, you're breaking what GCC stands for.
This also rolls over to Code::Blocks' default compiler and makes it clear, that if they go and ship a "GCC" compiler by default, it should also work like a GCC compiler.
--- Quote from: TDragon on August 10, 2013, 07:47:49 pm ---In the case of the static-by-default change, I carefully considered my options in the implementation and decided to have TDM-GCC reject -static-lib*** with an error precisely because this is safer than making it a no-op. Licensing concerns with the GPL (and associated exception clauses) make dynamic linking of libgcc and libstdc++ extremely dangerous to the casual user, so I want TDM-GCC to error out when the user assumes vanilla GCC behavior. This isn't an appropriate time or place for me to go into detail on the legal reasons behind this, so I hope you'll take my word for it as someone who has paid close attention to the discussions of this on the GCC and mingw-users mailing lists.
--- End quote ---
Well as you might have thought, I have my doubts about this, since linking stuff dynamically has usually less legal issues, than linking something statically by default, e.g. GPL doesn't allow you to link commercial stuff statically. If you have any resources regarding this, I'd be very interested to read them (you can also PM me if you don't want to post here any further).
--- Quote from: TDragon on August 10, 2013, 07:47:49 pm ---In order to keep the conversation constructive and focused on Code::Blocks, this will be my only contribution to the thread.
--- End quote ---
Thanks! Don't hesitate to post if you have further constructive comments though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version