One thing I find quite ugly is the usage of CMAKE_ prefix for our options/variables.
Could we avoid this at least for the new code? Tools also tend to group the options according to the variable prefix. Ideally we would decide on some kind of naming scheme and clean this up once but I'm a bit worried about existing scripts.

One thing I find quite ugly is the usage of CMAKE_ prefix for our options/variables.
Could we avoid this at least for the new code? Tools also tend to group the options according to the variable prefix. Ideally we would decide on some kind of naming scheme and clean this up once but I'm a bit worried about existing scripts.

What I like about the current setup is having two distinct variables for two different levels. As you can see in a commit-by-commit review, the first commit alone would have closed #3733 by changing the internal USE_DARWINSSL -> USE_SECTRANSP without changing the public cmake interface.

I have no opinion on the nicest possible naming for cmake options, as I am not a cmake expert.

I'm hoping this can be merged before the next release?

For clarity: building via CMake with the DarwinSSL/SecureTransport backend is currently broken (since 7.64.1), and this fixes it.

@past-due did you test this patch in your setup? If yes, that is valuable feedback and could help bringing this in. @MarcelRaad was so kind to review and merge the last cmake relates PR from me. Maybe he can find the time to have a look at this.

Unfortunately I don't have a Mac and we don't have CMake SecureTransport CI builds, so I'd prefer if someone else tried this out before merging. Looks good to me though.

@webmaster128, @MarcelRaad: Tested this patch on macOS 10.12 & 10.13. It successfully fixes the CMake SecureTransport builds.

I will look into adding CMake SecureTransport builds to the Travis CI config (as a separate PR).

Thanks! If noone else does, I'll merge as soon as I'm near a computer again, which will probably be late next week.

Merged now. Thanks again!