Kees,

I can't answer all of your questions, but

> 1. allow to specify paths to other libs/includes (from a read-only location) as I don’t like to copy things first (because Visual Studio does not always like it, as .lib, pdb etc belong together and get stored in the build results)

This is my main pain as well, and is what my change allows. For example:

  nmake /f Makefile.vc mode=dll WITH_ZLIB=dll WITH_ZLIB_LIBPATH=<my
zlib read-only location>\lib WITH_ZLIB_INCLUDE=<my zlib read-only
location>\include

> Q3: And how do the Makefile based solution related to the projects/solution based approach?

As far as I can work out they are not related at all. One of the
issues I had coming into building libcurl on Windows was figuring out
how to build it - should I use the projects or CMake or winbuild. I've
settled on winbuild for now.

> Q4: I'm not sure how easy the project/solution based approach can be used to extend cURL with other libs (zlib/libssh2/openSSL). So that is also why I put my original question.

If those libraries are in the expected location (../deps) I think they
work fine, there are projects for many (all?) of the combinations of
libs. but if you want to specify the locations yourself it is a pain.

Richard

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-03-21