[MONGOCRYPT-218] Wrap tls specific files if ifdefs Created: 11/Dec/19  Updated: 28/Oct/23  Resolved: 13/Dec/19

Status: Closed
Project: Libmongocrypt
Component/s: C library
Affects Version/s: None
Fix Version/s: 1.0.1

Type: Improvement Priority: Trivial - P5
Reporter: Kevin Albertson Assignee: Kevin Albertson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by PHPC-1509 Remove conditional compiles for tls f... Closed

 Description   

As a convenience for bundling (and the libmongocrypt build itself), wrap the TLS C files with ifdefs so they're safe to compile regardless of the TLS library used.



 Comments   
Comment by Jeremy Mikola [ 20/Dec/19 ]

Thanks for confirming. We removed them in the latest PHP PR.

Comment by Kevin Albertson [ 20/Dec/19 ]

Yes, _WIN32 should be defined by MSVC. libbson also relies on it being defined in order to use Windows specific headers an APIs: (example).

I found no references to MONGOCRYPT_IS_POSIX or MONGOCRYPT_IS_WIN in libmongocrypt or the history (using "git log -p -S MONGOCRYPT_IS_POSIX").

Comment by Jeremy Mikola [ 20/Dec/19 ]

kevin.albertson: I noticed that 2626864 also removed conditional compilation of the POSIX and WIN32 source files. They now depend on _WIN32 being defined. Am I correct to assume we can just rely on the Windows compiler to set this for us? I don't see anything in CMakeLists.txt that suggests we need to define it ourselves.

andreas.braun's PR for PHPC-1496 makes substitutions for MONGOCRYPT_IS_POSIX and MONGOCRYPT_IS_WIN. Do those date back to an earlier version of libmongocrypt? If so, can you point out when they were removed?

Comment by Githook User [ 13/Dec/19 ]

Author:

{'name': 'Kevin Albertson', 'email': 'kevin.albertson@mongodb.com', 'username': 'kevinAlbs'}

Message: MONGOCRYPT-218 wrap TLS code with ifdefs
Branch: master
https://github.com/mongodb/libmongocrypt/commit/26268640810361f5205730c42c5ca41287a50912

Generated at Thu Feb 08 09:08:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.