> 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

Received on 2017-01-19