[nanomsg] Re: Release packaging and build systems
- From: mike <mike@xxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 24 Jul 2013 01:18:06 -0700
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
>
Other related posts:
