[MONGOCRYPT-152] Standardize the directory structure of the generated libmongocrypt assets Created: 10/Jun/19 Updated: 04/Sep/19 Resolved: 30/Jun/19 |
|
| Status: | Closed |
| Project: | Libmongocrypt |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Matt Broadstone | Assignee: | Roberto Sanchez |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Build libmongocrypt library |
| Description |
|
It's presently difficult to create automation around linking to libmongocrypt, because the contents of the tarball are different for different architectures (linux has a top level libmongocrypt-static.a, while OSX has it in lib64/libmongocrypt-static.a). It would make life much easier for embedders to create an SDK for this library if there was a well-defined directory structure to find the required libraries. |
| Comments |
| Comment by Roberto Sanchez [ 30/Jun/19 ] |
|
matt.broadstone, thanks for the follow-up. You are correct that some distributions still have lib64 directories while others have eliminated the 32-bit/64-bit distinction at that level of the directory hierarchy. I'm pleased that the unified tarball meets your requirements. |
| Comment by Matt Broadstone [ 30/Jun/19 ] |
|
roberto.sanchez I think this was confusion because e.g. the amazon linux build was installing to lib64 instead of lib, and might just be a requirement of that distribution. I think we can close this now that we have the unified tarball. |
| Comment by Roberto Sanchez [ 27/Jun/19 ] |
|
matt.broadstone, can you point me to an example of an SDK after which to model the implementation? Or, perhaps you could provide a more detailed description of what you are thinking? |