Producing code that works cross platform is a significant feat. Producing code that builds using different compilers and build environments is the next level of horror.
Of course, the easy out is to say your platform is the best, and your favorite compiler/ build tool environment is the best and everyone should just convert to your right way of thinking. At any one time, one of the persons is probably close to the truth regarding either point. The trouble is, that there are many others in the room and it is more inclusive if our collaboration did not have a "my way of the highway" level of chauvinism concerning the neglect for accommodating other popular tools and platforms.
I don't think any of this is particularly intentional. If your compiler has a feature that works on yours but not on others, chances are you are not even aware that there is anything odd about what your code is doing. It could be utterly non standard, against spec on legal C, but you have no idea because it compiles just fine and behaves as you expect it would.
So what's the big deal?
The big deal is that people using Apple, Intel or Microsoft compilers either can't compile, or the resulting code is faulting/ memory leaking like crazy. For no apparent reason.
The method of insuring that cross platform works is to have a tester do a sanity check build on all platforms in the daily or bi-daily sync and build of current check-ins. Anyone that breaks the build on a platform gets massive points off for bad behavior and learns how to avoid such in the future. After a while you get a sense for what sorts of things have serious impacts on the different platforms.
The same is true of writing code that builds binaries with identical code behavior regardless of the compiler.
Anyway, it would be surprizing to me if there were any other compiler besides gcc that could build the 2.3 code tree. I don't yet know enough about the 2.4 changes, but from the cases I have seen so far, it is unclear what the intent of some of this unorthodox code is. Not knowing the intent makes it difficult to translate to equivalent statements in another compiler. Take the following for example:
#define CF_TRANS_BOOL_SEQ(ARG_letter, ARG_value) \
{ .type = CF_TRANS_BOOLEAN, .letter = ARG_letter, \
{ .bool_value = ARG_value } }
Thankfully, this code has been replaced in 2.4 by some thoughtful contributor. The prior code would only build in gcc, because those instructions .type etc are gcc assembler directives. Someone was recommending that they try using the INTEL compiler rather than Microsoft's because at least it was C99 adherent. Well, in the code we have zero length structs. What the code has is structs with no elements. For example, in common\game.h:
struct {
/* Only used at the client (./client/). */
/* Nothing yet. */
} client;
This is not legal C, it only works because of a GCC C extention that allows empty structs (gnu docs). Probably these are freeciv placeholder declarations for future use, and the gcc compiler allows them. The trouble is that a zero length struct is illegal both in C, and in C99 (see 6.7.2.1 if you are in a pedantic mood). As for translating this declaration, you could place a dummy value entry of size char to make it work with compilers that are conformant to spec. If you don't use char, then you may well run into muck ups if any code is data dependent, assuming specific struct sizes, which appears to be the case in the serialization code. Could be written better, but what the heck.
Anyway, my first impression is that upgrading the freeciv code to be non compiler specific could be a multi week undertaking, and there may be few people who would be interested in its benefits, so my approach will be to simply use WinGDB within Visual Studio. I may revisit this if anyone is interested in maintaining the discipline of keeping freeciv agnostic about compiler choice.
For my part, I don't much mind dropping into debugging interfaces I left 20 years ago. It is nostalgic. I am only getting a fraction of the Visual studio advantages with windbg, and for others, it may be completely irrelevant for those who have been using the gdb interface for years. I understand- I did things with such interfaces for a good portion of my career. Nothing wrong with it. You don't catch things as quickly, but it is certainly an effective technique, so by all means stay with what you are comfortable with.