Patrick Welche <prlw1%cam.ac.uk@localhost> writes:
> Because of my long held view that pkg-config was invented because learning
> m4 was seen as too much of a time investment. Test for features, not
> version numbers.
I saw it from the other side, as a way to replace "foo-config" programs
that were often bundled with libraries, with a data file and a host
program, which was more cross friendly. And as a way to avoid a large
number of autoconf macros, specialized for each package, that dealt with
both headers and libraries, automatically adding -I and -L/-R, and
dependencies of libraries. It seemed that the notion was sound that the
data changed per package, but that there was an underlying program that
could be written once.
> Case in point: do packages really really need fontconfig 2.13.0?
Hard to say, but the notion that a package that uses fontconfig can know
in which version something was added is not so crazy. The more general
feature vs version I agree with, but that's much more about different
implmentations of an interface (like POSIX :-).
> On top of it, maintainers tended to be experts in the field of their
> package, and look with suspicion at patches for configure.{in,ac} from
> unknown contributors, which then seems to have lead to a dislike for
> autotools. What will you use now? cmake? meson? jam? ...? Maybe this
> is randomly inflammatory ;-)
I continue to prefer autoconf, as all the replacements seem quite
troubled. In addition to encouraging os-specific code, they seem to
deal with cross less well, and cmake in particular seems to require
users of any cmake package to have a C++11 compiler.
But I am ok with autoconf using pkgconfig support.
> (What to do about libarchive.pc was answered by wiz -
> investigating...)
And, we could add a pc file to base, and then have pkgsrc symlink it
instead of synthesizing, but we'd have to synthesize one on older netbsd
anyway, so it's probably not worth it.
Attachment:
signature.asc
Description: PGP signature