Hi Martin,
> just catching up to this thread; apologies for not getting to it sooner.
> If
> you want an opinion on something quickly it's better to add me in
> separately to Cc: so that I notice it immediately.
>
> [email protected] said:
> > So, I decided to do a quick test on this fix while I was running a
> > build at work. It seems like there is a much easier fix for this;
> though we
> > would still want the additional configurations since it does still
> require
> > the definition added to the projects.
>
> I'm no Visual C++ expert but the additional configurations you are
> proposing seem like the right way to do things.
>
> Having said that, is all this work just to make Static Linking really
> worth
> it? Why would static linking be preferable to shipping libzmq.dll?
A fairly reasonable example is the tool which started me using zmq
in the first place. Basically I'm processing 2.25 million files (blobs)
from Oracle and 1.1 million from Perforce building a database of dependency
information for SWTOR. The problem with the dll approach though is that we
have 16+ environments and hundreds of server boxes. Rolling out a new
version of the tool based on the environment would be very time consuming
and this is going to be in heavy development over the next couple of months.
As such, it is best for my needs to statically link as much as
possible such that I just have to build the tool for the given environment
and it will work. Dll dependencies are still not really "solved" in Windows
with the side by side assemblies, better yes but still problematic.
> If the issue is divering versions of libzmq.dll (i.e. DLL hell) on the
> installed system then the solution I would prefer *in the long run* would
> be that someone volunteers to do the work to provide an MSI
> redistributable
> of the "ZeroMQ runtime" for Win32, with all the appropriate SxS assembly
> magic or whatever it's called so that multiple versions of the DLL can be
> safely installed concurrently and it all "just works".
Yeah, I wish.. :) Unfortunately it still doesn't work very well in
practice and running around and installing dll's on this many machines is
near impossible.
> > Basically I missed the fact that the project files were using
> > non-compiler defined items and using standard "VC" inserted items. What
> I
> > mean is that instead of looking for "_MSC_VER" to detect a vc compile,
> it
> > uses "_WIN32", and of course "DLL_EXPORT". Those are not defined in the
> > compiler and are simply inserted if you use VC to generate the projects
> > using wizards. Not a problem, that is likely the most common use case.
>
> I didn't know that. The reason I used _WIN32 is that it is defined by
> Mingw
> (GCC for Win32), so I assumed it was a universal "platform define" like
> "linux" on Linux, etc. I would prefer to keep the Win32 support as generic
> as possible, so that GCC would continue to work.
My apologies, it is defined by the compiler and is always defined.
I was thinking of something else unfortunately when I wrote that. Having
said that though, just out of habit I still use _MSC_VER, so I can check
compiler features. For instance, with VC10 and gcc 4.2+ (or there abouts),
I use some of the new features of the compiler because they make a huge
performance difference. Mostly the move constructors of C++0x is a very
impressive performance boost in string and simd processing items.
So, this suggestion is basically moot unless you do want to
eventually start using some of the C++0x stuff.
> > Given this though, I suggest the following changes:
> >
> > 1. Don't look for "_WIN32": use the guaranteed "_MSC_VER" so folks with
> > unique build requirements don't have to screw with adding an additional
> > definition to their projects. I.e. "#if defined _MSC_VER" replaces "#if
> > defined _WIN32". This is similar to using "__GNUC__", you know the
>
> See above. Is there really no guaranteed platform define on Win32? This
> would mean a separate maze of #ifdefs for each different supported
> compiler.
Yeah, I was mixing it up with some other issues from Windows. I'm
used to the maze of if/else unfortunately, it's about the only way to get
things working correctly for our purposes. Not that I'm doing any console
dev lately but _WIN32 is defined even for an XBox 360 build and you have to
use a different detection patterns for it.
> > 2. Still add in the check for "ZMQ_STATIC" so we can correct all the
> > link errors and warnings. But, do it differently than I initially
> > mentioned. I wasn't paying attention and missed the "DLL_EXPORT" usage.
> > That's another VC wizard inserted item, not a real compiler define.
>
> If I understand this correctly, it would mean that any *application*
> including zmq.h would have to define ZMQ_STATIC if it was using a static
> library, and not define anything to get the default (DLL) behaviour?
I think you have this correct. Basically if you are statically
linking you define the above and errors/warnings go away. This is
unfortunately standard practice for things which support both static and dll
linkage on Windows. Examples of some other libs that end up doing the same:
zlib, tinyxml, libpng, libevent etc. Pain in the ass but pretty standard.
> > 3. Please move the checks into a different header so zmq.h and
> > zmq_utils.h can share the same behavior. That messed me up a couple
> times
> > when I forgot to change one or the other. :)
>
> This is tricky since zmq.h and zmq_utils.h are shipped as API headers so
> they should be as self-contained as possible. In the 0MQ core itself the
> various Windows stuff has slowly been migrating to windows.hpp but it's
> still a mess.
Hmm, I'll take a look at windows.hpp, maybe that can be cleaned up
and unified such that zmq.h/zmq_utils.h don't need the definitions at all.
Unfortunately though, it will be a bit before I can get back to
this. I'm actively using zmq right now for this tool at work and while zmq
is working fine, some of our file types are giving me some serious
headaches.
KB
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
