Hi Kelly, 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? 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". > 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. > 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 compiler > defined it and unless someone is intentionally playing games, there should > never be a problem using that check. See above. Is there really no guaranteed platform define on Win32? This would mean a separate maze of #ifdefs for each different supported compiler. > 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. But, it > does make things nice and easy, in a static build just define it. > Everything gets a "__declspec( dllexport )" which is fine and does not > generate any warnings it is the imports which cause the annoying warnings. 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? > 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. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
