Users of MIT Kerberos expect the MIT pkgconfig files to be installed,
and won't work without them. For example, this breaks anything that
links against libcurl (ftp/curl) when curl is built with base GSSAPI.
Details
Details
- Reviewers
des ngie cy - Group Reviewers
krb5 - Commits
- rG0c13e9c3c464: krb5: Install pkgconfig data
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 66141 Build 63024: arc lint + arc unit
Event Timeline
| krb5/Makefile.inc | ||
|---|---|---|
| 12 | Can we either extract this from crypto/krb5/src/configure or add a sanity check which fails the build if it doesn't match? | |
| krb5/libdata/Makefile | ||
|---|---|---|
| 39 | ||
Comment Actions
I’m a bit surprised these files don’t get generated by configure properly. I wonder if they’re created, but never checked in…
The vendor import process may require polishing a bit in order to generate these files automatically.
Just trying to avoid a situation like crypto/openssl has right now from growing further with this new component.
CC: @cy
| krb5/libdata/Makefile | ||
|---|---|---|
| 35 | This switches to the bmake form 100% instead of using a mix of AT&T / bmake variable names. | |
| krb5/libdata/Makefile | ||
|---|---|---|
| 37 | Don’t we have integration for PCFILES today? If not, that seems like a minor deficiency that’s easy to solve in bsd.lib.mk . | |
| krb5/Makefile.inc | ||
|---|---|---|
| 17 | Generally speaking, DESTDIR shouldn’t be encoded in variables like this: this pattern requires users to override the value with DESTDIR in it instead of it being programmatically specified at runtime/as part of the appropriate buildworld stages. | |
| krb5/Makefile.inc | ||
|---|---|---|
| 12 | configure should generate these files for us if we pass in the right values. We shouldn’t be parsing autoconf files (that would make the build process extremely brittle). | |
| krb5/libdata/Makefile | ||
|---|---|---|
| 37 | this is only needed here because we build the pc files, it wouldn't be in a situation where we just have the pc file in src. so i'm not sure it's right to add this to bsd.lib.mk? (on the other hand, perhaps it wouldn't do any harm.) | |
Comment Actions
fwiw I agree with ngie that ideally we should just get Cy to generate and commit the .pc files, I don't know why I didn't think of it earlier
Comment Actions
i'm fine with that approach too, but we should do something soon since we need to fix ports.
Comment Actions
I agree with @ivy about this landing now. If we quickly pivot to check in the .pc files later, I say go for it.
Comment Actions
i'd like an approval from cy before landing in case there's a specific reason we don't already install these, but otherwise, i intend to land this and D51841 tomorrow; if we decide to pre-generate the .pc files later that won't change anything in ports as the same files will exist.