[MONGOCRYPT-139] kms_message cmake cleanup Created: 19/Feb/19  Updated: 27/Oct/23  Resolved: 17/May/19

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Albertson Assignee: Roberto Sanchez
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Build libmongocrypt library

 Description   

Let's audit the CMakeLists.txt of kms_message. I'm hazy on how the install targets and package configuration work.

kms_message won't (for now) be distributed as a separate library. It will be statically linked with libmongocrypt. Really, we just need it to work well enough so we can statically link against it everywhere we build libmongocrypt. This ticket might be a no-op, but let's at least spend some time double checking this.



 Comments   
Comment by Roberto Sanchez [ 17/May/19 ]

So, having a SONAME now would make future changes easier, since adding a SONAME where there was not previously one can be somewhat disruptive from a build/deployment perspective. In my mind, it is better to cause that disruption before the first release. Additionally, if we are still entertaining the possibility of packaging for Debian and/or Fedora, both of those distributions will require that the library carry a proper SONAME.

I recommend creating a new ticket and blocking CDRIVER-2971 and CDRIVER-2972 with it.

Comment by Kevin Albertson [ 17/May/19 ]

not shipping any kms_message components

We do need to ship the shared kms_message for shell. Unless there's a reason, I don't think it hurts to ship both static/shared kms_message, unless you mean something else.

possibly adding more sensible versioning/SONAME support to libmongocrypt (assuming that it is desirable to support more robust dynamic linking of libmongocrypt)

Hmm, maybe we do need to do this before releasing. Though we should probably aim to keep things ABI stable, if we do make an ABI break later, I imagine it'll be less destructive if we have an SONAME in place, but I'm also not super familiar with this. Should we create a separate ticket?

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