krb5: Obtain KRB5 version number automatically from sources

[cy]

Summary

Obtain the KRB5 version number from patchlevel.h and from ./configure
in the upstream provided sources. This avoids a version mismatch
when updating MIT KRB5 from upstream and forgetting to update the
version number in autoconf.h and in krb5-config.

Suggested by: des

Test Plan

Running here since Friday (Aug 15).

[cy]

Please pay special attention to the makfiles outside of krb5/. Is it a wise idea to include headers from a relative path, i.e. ${.OBJDIR}... or use ${INCLUDEDIR}/private/krb5 to include autoconf.h?

[des]

Cy, please install freebsd-git-devtools and use git arc to create and update Phabricator reviews, as described in the committer's guide.

[cy]

Use git diff -U99999.

[ivy]

krb5/include/autoconf.hin

644

do you not re-run ./configure when importing a new release (to pick up new macros, etc.), in which case this should be updated as a side effect?

[ivy]

In D51989#1187627, @cy wrote:

Please pay special attention to the makfiles outside of krb5/. Is it a wise idea to include headers from a relative path, i.e. ${.OBJDIR}... or use ${INCLUDEDIR}/private/krb5 to include autoconf.h?

would it be easier to use ${OBJTOP}/krb5/whatever rather than trying to construct a relative path?

krb5/libdata/Makefile

11

note that libdata is going away in D51986, so this will need to move somewhere else (Makefile.pc is probably fine).

krb5/util/build-tools/Makefile

23

why is the logic here different from libdata/Makefile?

[ivy]

krb5/lib/apputils/Makefile

26

there's only one build-tools directory, so why list this twice?

[ngie]

Please check in the minimum set of files needed to get the build to function properly, e.g., krb5/include/autoconf.h. If that's done, all of the proposed Makefile complexity can be dropped (CLEANFILES is missed BTW in the proposed change).
If someone doing the vendor import fails to do import the new release properly (which includes running ./configure), it's an issue with whoever did the update and/or the overall update process.
FreeBSD has matured to the point that (IMHO) there shouldn't be single maintainers for third-party packages, like Kerberos. If the barrier of entry was lowered, it would be easier for others outside the primary maintainer to pitch in and help with version updates.
See this differential for potential inspiration on how I'm proposing it be achieved with OpenSSL: https://reviews.freebsd.org/D51663 . It's probably more complicated than you need, but leveraging common patterns, e.g., BSDmakefile, and specifying the right targets/logic can ensure that the right sources get committed to the source tree and vendor imports are done in a less error prone way.

[cy]

krb5/include/autoconf.hin

644

./configure may or may not be rerun. Typically what I do is build the port and copy autoconf

krb5/lib/apputils/Makefile

26

Nope. There are two build-tools directories. One for lib and the other for obj-lib32 (32-bit compatibility). Without this 32-bit compatibility fails to build.

krb5/libdata/Makefile

11

I will look ad D51986 and reply later.

krb5/util/build-tools/Makefile

23

IMO this is a better approach.

[cy]

In D51989#1188086, @ngie wrote:

Please check in the minimum set of files needed to get the build to function properly, e.g., krb5/include/autoconf.h. If that's done, all of the proposed Makefile complexity can be dropped (CLEANFILES is missed BTW in the proposed change).
If someone doing the vendor import fails to do import the new release properly (which includes running ./configure), it's an issue with whoever did the update and/or the overall update process.
FreeBSD has matured to the point that (IMHO) there shouldn't be single maintainers for third-party packages, like Kerberos. If the barrier of entry was lowered, it would be easier for others outside the primary maintainer to pitch in and help with version updates.
See this differential for potential inspiration on how I'm proposing it be achieved with OpenSSL: https://reviews.freebsd.org/D51663 . It's probably more complicated than you need, but leveraging common patterns, e.g., BSDmakefile, and specifying the right targets/logic can ensure that the right sources get committed to the source tree and vendor imports are done in a less error prone way.

Agreed.

As with other vendor imports the committer should remember to update version strings. This will simplify the Makefiles.