> I'm still working through your patch and should have some comments this week. >
I've now used the applied patch (had to be done in a unix world) to build and deploy cUrl and our downstream dlls. So this patch isn't a show stopper for us. On the other hand I still have to use the MAKE="NMAKE /E" hack which then allows me to override the internal workings of MakefileBuild.vc. If I was the one supporting this build system I would say that that puts me outwith "supported usage" - the more so since the parameterisation I then use isn't listed when I say "nmake /f Makefile.vc". As a builder and deployer this makes me nervous and I need to check that the makefiles haven't changed between releases. In order for this build to add any value for me I'd need to be able to set BASE_NAME and BASE_NAME_DEBUG (patch attached). I need to do this to proactively avoid DLL hell further down the line. It would also make me more comfortable to know that I was using supported options (by adding them to the help text). The ones I use which are not in the help text are ZLIB_LFLAGS BASE_NAME BASE_NAME_DEBUG ZLIB_CFLAGS ZLIB_LIBS SSL_LIBS Your example uses the last three, plus LIBPATH, SSH2_LIBS, SSH2_CFLAGS, so at least those should be added to the help text. It occurs to me as I type this that you can also finesse the huge path issue by just allowing a used to short cut in the setting of CONFIG_NAME_LIB in Makefile.vc. Hope this helps Rod
0002-Modify-Kees-s-patch-to-allow-command-line-override-o.patch
Description: Binary data
------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
