Hi Mato, I don't really follow all the build system complexities. Do you have any opinion on MSVC + static linking issue?
Martin On 8/9/2010, "Kelly Brock" <[email protected]> wrote: >Hi, > >> 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. >> >> >> >> >> _WIN32 is for the platform, _MSC_VER is for Visual Studio. Visual Studio >> isn't the only compiler for Win32/Win64 and _MSC_VER will break on those >> other compilers, for example MinGW and Cygwin. > > True, I just have a habit of being very explicit about things. In >this case I've tested the change for VC and someone with the other compilers >could test it for others on a branch, if/when all happy, I'd suggest not >using _WIN32 still and in config.h or somewhere detecting the known >compilers and then defining ZMQ_WIN32 or something along those lines. Leave >a pragma error or warning for unknown compilers which says "untested". This >is not much of an issue for other platforms but it is similar in concept to >why you use autoconf on Linux, everyone is just a little different, be safe, >not sorry. Well, not sorry, just getting yelled at by folks with really >different setups sucks. :) > >> _MSC_VER should only be for fruity #pragmas and particulars of MSVC, such >> as lack of C99 headers, broken inline, etc. >> >> MSVC is very retarded with static libraries, Winsock for example doesn't >> work properly unless you have WIN32 defined and even MSVC 2010 >> conveniently removes it from the default configuration compared to >> application targets. > > Totally agree with the retarded statement. VC and most Win32 >compilers for that matter, have a serious set of failures due to the >platform expectations and SDK silliness, not really the compilers >themselves. Come on, one of my favorites from the SDK: No one in their >right mind would ever write a function called "CreateWindow" in a namespace >now would they? Good you agree because if you try; it's a macro in the SDK >and as such if you "don't" include Windozer.h in various files which use it, >you will get nice link errors everywhere looking for "your >namespace::CreateWindowEx" or the Unicode version instead of what you named >it.. :/ I really despise namespace pollutions and WinSDK is an absolute >nightmare of problems with all its crappy ass macro's. > > >KB > >_______________________________________________ >zeromq-dev mailing list >[email protected] >http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
