I'll be honest. I've completed looked the other way when looking for libraries that are MinGW only. It requires a different set of dependencies, and extra files. Yes, there are a lot of ups and downs but having to have those extra files is a make or break for specific things I've developed in the past. This is purely my own opinion, and I'd rather modify it to work with MSVC, as I have with other libraries, than to use MinGW. It's almost like putting it into another 'class' in my point of view. I understand this could be considered nonsense but just figured I'd throw that out there. I'd end up adding all nanomsg files to a project and compiling that way before dealing with MinGW.. =P... I've found that lots of libraries even things such as udis86 that I've dealt with recently.. I just skipped to adding it directly to the project and calling functions as if it was built into my application rather than as a library. I understand the issues with automake, etc, etc.. and it's becoming a pain in the ass with MSVC and the different solution version files. Just last week I installed 2005, 2008, 2010, and 2012 just to deal with a compilation.... nightmare. I'll have no issue in the future attempting to branch off a MSVC 6 compilable version.... I love nanomsg! I am late to the game of these types of communication products but am building several applications using them as the main protocol already. I cannot wait until it's productive stage, and I should put forth effort into helping fix the bugs myself as well. I had to recently move a single product out of 4 to ZeroMQ due to (NN_QUEUE_NOTINQUEUE) causing database synchronization issues when crashing... but I guess I cannot complain and want to thank you Martin for all the hard work on nanomsg, and zeromq. I am finally finishing up three crucial projects this week, and I'll check into this bug myself soon. I have to get my head wrapped about the nanomsg internals. I do plan on helping out in the future for sure if I have any additions that you guys like... Keep up the great week. I'll still use it regardless of MinGW or not :) Thanks, Mike ___________________________ Mike Guidry mike@xxxxxxxxxxxxxx Mike Guidry Group Inc. On Jul 24, 2013, at 12:38 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote: > On 23/07/13 15:10, luca barbato wrote: > >>> The problem is that Win devs work with MSVC. Asking them to use MinGW is not >>> realistic. >> >> There are 2 problems, one is if you have contributor using only msvc >> and wanting to touch only system native tools, >> that is a near impossible solution. Relaxing it so they can have a >> generator for a msvc project is simple, cmake can do that >> out of box, but then they must learn cmake and update it from their >> msvc changes. >> >> The other is _usage_ on windows. In that case as long there is a >> windows build with debug symbols and headers they are happy. >> >> The second is easy to achieve with both build systems and actually >> easier with autotools. > > True. > > So the alternative is to ditch MSVC support entirely and depend only on MinGW > on Windows platform. The solution is appealing as it would allow us to remove > the cmake support and end up with a single build system. > > The downside is, obviously, making it hard for windows-native-only developers > to participate in the development. However, the restriction is acceptable. > With the current market situation I would guess that Windows devs would treat > using minGW as a possibility to learn something from the mainstream > programming, rather than as using an obscure build tool. > > That being said, what are the other downsides on MinGW. Does it introduce > additional run-time dependencies? Does it make hard to debug? Etc. > > Martin >