Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake: migrate from USE_DARWINSSL to USE_SECTRANSP #3769

Closed

Conversation

@webmaster128
Copy link
Contributor

commented Apr 12, 2019

Closes #3733

@bagder bagder added the cmake label Apr 12, 2019
@jzakrzewski

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

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.

@webmaster128

This comment has been minimized.

Copy link
Contributor Author

commented Apr 12, 2019

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.

@past-due

This comment has been minimized.

Copy link

commented Apr 17, 2019

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.

@webmaster128

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

@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.

@MarcelRaad

This comment has been minimized.

Copy link
Member

commented Apr 18, 2019

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.

@past-due

This comment has been minimized.

Copy link

commented Apr 18, 2019

@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).

Copy link

left a comment

Tested on macOS 10.12 & 10.13.
Successfully fixes the CMake SecureTransport builds.

@MarcelRaad

This comment has been minimized.

Copy link
Member

commented Apr 21, 2019

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

@MarcelRaad

This comment has been minimized.

Copy link
Member

commented Apr 27, 2019

Merged now. Thanks again!

@lock lock bot locked as resolved and limited conversation to collaborators Jul 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.