hi
please excuse my submission style. Each software project has different
rules, some projects do not accept patches but only full files, other
projects vice versa.
I don't know why this makefile is built in such a complex way and I agree
that that should be discussed.
I'm not a c-ares developer and just wanted to push my changes back to the
core project to avoid that every MSVC 2013 dev has to adapt it on his own.
I recommend to discuss the complexity of the makefile withi the c-ares
developers and to add my changes soon to make C-ares compatible with MSVC
2013.
Thank you for your effort!
Kind regard,
Torben Dannhauer
-----Ursprüngliche Nachricht-----
Von: c-ares [mailto:c-ares-bounces_at_cool.haxx.se] Im Auftrag von Gisle Vanem
Gesendet: Freitag, 22. November 2013 14:35
An: c-ares hacking
Betreff: Re: MSVC 2013
"Torben Dannhauer" <torben_at_dannhauer.info> wrote:
> please find attached my extended Makefile.msvc to allow compilation
> with Visual Studio 2013 RTM.
You should have simply provided the diffs:
@@ -125,6 +125,8 @@
CC_VERS_NUM = 110
!ELSEIF "$(_NMAKE_VER)" == "11.00.60315.1"
CC_VERS_NUM = 110
+!ELSEIF "$(_NMAKE_VER)" == "12.00.21005.1"
+CC_VERS_NUM = 120
!ELSE
! MESSAGE Unknown value for _NMAKE_VER macro: "$(_NMAKE_VER)"
! MESSAGE Please, report this condition on the c-ares development
----------
But I fail to understand why this makefile has to be this complex. It uses
some suspicious heuristics to assert the MSVC compiler version; thinking
that $(_NMAKE_VER) is related to the CL version. Is it really safe to assume
they are correlated? An old nmake can just work fine with a new MSVC
compiler, or not?
Can it be simplified to just check for 2 CC_VERS_NUM? An old and a new?
Or drop '/Gz' and '/RTCsu' all together.
--gv
Received on 2013-11-28