7 ms·

I understand how we got here, but the pkg-config format being the least common denominator of build-tool package discovery makes me sad. I support it, barely,

I understand how we got here, but the pkg-config format being the least common denominator of build-tool package discovery makes me sad. I support it, barely, in most of my packages, but I never use it. cmake and vcpkg have completely supplanted it in my workflows, and cmake is quickly approaching the point where we might be able to describe it as the new least common denominator. Everyone hates cmake, of course, but to paraphrase Stroustrup: there are only two kinds of tools, the ones people complain about and the ones nobody uses.

nerdponx 4y ago
What's so bad about the format?
- mathstuf 4y ago
  Flag soup is terrible for dependency management. It only works for a single compiler (family), there's no semantics of what each flag might mean, undefined ordering or grouping of flags like `-ffast-math` or `-fno-fast-math` (which are ABI-affecting) means you don't know what you'll actually get. More fun, if you have multiple prefixes of dependencies, one `-L` can change what any following `-l` flag means (and is primarily why I think that absolute paths to libraries is far better on the link line). FD: CMake developer
  - saurik 4y ago
    I feel like pkg-config should really be returning a list of linkable libraries as files instead of using -L/-l, but I figure it is having to do the latter because of something with libtool and .la, right?
    - mathstuf 4y ago
      How much does libtool matter these days? AFAIK, distros `rm -rf %{_libdir}/*.la` without a care.
Galanwe 4y ago
I don't understand why you mention CMake. CMake is not a build system, it does not replace make, or vsproj, or even pkgconfig. It's a _meta_ build system - that is it generates makefiles/vsproj/etc. CMake does not _find_ libraries magically. You can have CMake modules to use pkgconfig, or custom search scenarios, or whatever else you want, to find libraries and flags. Really it's two different things working at different levels, one does not replace the other.
- gabereiser 4y ago
  This is correct. CMake is a configuration tool, not a build system. It generates make/xcodeproj/vcsln/or the like. It's meant as a replacement for autoconf or the ./configure scripts previously used to auto-configure Makefiles.
  - mathstuf 4y ago
    FWIW, I consider CMake a "build system" in that it defines a set of semantics to describe a build. It uses "build tools" to implement these semantics. FD: CMake developer
  - mananaysiempre 4y ago
    CMake-generated Makefiles call CMake at build time—unlike autotools where m4 and Perl are not required once you’ve built the distribution tarball. If you really really want, with autoconf alone you can even write the config.h by hand, the template contains lists all the defines that should go there. (With automake added to the mix, you probably can’t.)
- mort96 4y ago
  CMake has an independent module resolution system with Find*.cmake files. It's not great, and not a lot of libraries support it, but if you're on a Linux system you may find those Find*.cmake files in /usr/lib/cmake.
  - nickelpro 4y ago
    I'm referring to the dedicated PackageNameConfig.cmake files that you'll find pretty much everywhere these days, not the old FindPackage.cmake modules.
gabereiser 4y ago
Exactly my thoughts. We can do better than both these solutions but it's going to take an industry to adopt the practice. I like what vcpkg is doing... I'm a cmake guy myself, but I always found pkg-config to be useful to the point where you're upset when it's not present and that presents a problem. Build chains need consistency, reproducibility, and some form of order.
albertzeyer 4y ago
What's the problem with pkg-config? You mean the slightly inconsistent behavior across those different implementations? Are they really relevant in practice? I never really had problems with it.
mananaysiempre 4y ago
AFAICT to use CMake for dependency discovery you have to either be or require CMake, the full interdependent coupling of a macro language and half-of-a build tool. Regardless of the merits of either part, that’s a lot to implement and a lot to commit to. Pkg-config, on the other hand, is rather small. The initial implementation was bulky enough to annoy people into at least two rewrites, but the concepts are few and the requirements on the host build system practically nonexistent. (One place where the CMake-like approach won is the editable form of scientific documents. I like TeX to bits, but you can’t even tokenize it without being TeX, and even if you are essentially the only operation you can do on it is typeset, those even feed into each other. Thus the current two decades of half-working AST-producing parsers and ugly HTML generators and DVI extractors and whatnot.) So, no, I’m not the least bit sad CMake didn’t win the game, not any more than I’m sad autom4te didn’t. Pkg-config isn’t ideal, but as far as not forcing the whole world into its image it’s miles better.
- jcelerier 4y ago
  > Pkg-config, on the other hand, is rather small. The initial implementation was bulky enough to annoy people into at least two rewrites, but the concepts are few and the requirements on the host build system practically nonexistent. yet all these years and it's still a pain on Windows with the Visual Studio world. And if it doesn't work with VS (as in, you can have a VS solution which uses pkg-config automatically to find libraries / flags / ... without having to fudge with scripting it yourself) it's 100% irrelevant to any cross-platform discussion (and thus most of C / C++ / native ... software development).
  - mananaysiempre 4y ago
    There’s “builds on Windows” cross-platform and there’s “works on a big-endian MIPS router with a 2.6.x series Linux kernel and an ancient Busybox” cross-platform. And a lot more. All of those are important to somebody. So “100% irrelevant to any cross-platform discussion” for lack of Windows support sounds overexaggerated to me, let alone for lack of Visual Studio support. Also, well. Before the article under discussion, there was no decent Windows support, because no pkg-config user was willing to donate their time or spend their money to improve the Microsoft Windows ecosystem. Now somebody came around and there is. Perhaps that will happen to the Microsoft Visual Studio ecosystem as well, in time, or perhaps not. Probably not going to be me, though. (In the case of CMake, the support appeared when Microsoft spent their money on improving the Microsoft Visual Studio ecosystem, because C++ programmers not using Visual Studio became numerous enough, and CMake became popular enough among them, that not being to interoperate with their work diminished the IDE’s value. I don’t see that happening with pkg-config, mainly because a lot of its usage is in the C world, and Microsoft doesn’t really care all that much about that.)
tialaramex 4y ago
> to paraphrase Stroustrup: there are only two kinds of tools, the ones people complain about and the ones nobody uses. Yeah, no, one of the interesting things is that we routinely use some tools without even really thinking about them - we don't complain about them because we never think of them at all even though we're using them, they're that unobtrusive. In its original context Bjarne's claim is belied by the StackOverflow surveys. You can choose to imagine that "nobody uses" Rust, which famously keeps topping the charts, but not far down the list is Python. It would be nice if our industry could manage better than .pc files but I'm an old man and when I wrote all my early code this didn't exist, your best chance was to cargo cult some auto-detection of common libraries.

nerdponx 4y ago

What's so bad about the format?

mathstuf 4y ago
Flag soup is terrible for dependency management. It only works for a single compiler (family), there's no semantics of what each flag might mean, undefined ordering or grouping of flags like `-ffast-math` or `-fno-fast-math` (which are ABI-affecting) means you don't know what you'll actually get. More fun, if you have multiple prefixes of dependencies, one `-L` can change what any following `-l` flag means (and is primarily why I think that absolute paths to libraries is far better on the link line). FD: CMake developer
- saurik 4y ago
  I feel like pkg-config should really be returning a list of linkable libraries as files instead of using -L/-l, but I figure it is having to do the latter because of something with libtool and .la, right?
  - mathstuf 4y ago
    How much does libtool matter these days? AFAIK, distros `rm -rf %{_libdir}/*.la` without a care.

Galanwe 4y ago

I don't understand why you mention CMake. CMake is not a build system, it does not replace make, or vsproj, or even pkgconfig. It's a _meta_ build system - that is it generates makefiles/vsproj/etc. CMake does not _find_ libraries magically. You can have CMake modules to use pkgconfig, or custom search scenarios, or whatever else you want, to find libraries and flags. Really it's two different things working at different levels, one does not replace the other.

gabereiser 4y ago
This is correct. CMake is a configuration tool, not a build system. It generates make/xcodeproj/vcsln/or the like. It's meant as a replacement for autoconf or the ./configure scripts previously used to auto-configure Makefiles.
- mathstuf 4y ago
  FWIW, I consider CMake a "build system" in that it defines a set of semantics to describe a build. It uses "build tools" to implement these semantics. FD: CMake developer
- mananaysiempre 4y ago
  CMake-generated Makefiles call CMake at build time—unlike autotools where m4 and Perl are not required once you’ve built the distribution tarball. If you really really want, with autoconf alone you can even write the config.h by hand, the template contains lists all the defines that should go there. (With automake added to the mix, you probably can’t.)
mort96 4y ago
CMake has an independent module resolution system with Find*.cmake files. It's not great, and not a lot of libraries support it, but if you're on a Linux system you may find those Find*.cmake files in /usr/lib/cmake.
- nickelpro 4y ago
  I'm referring to the dedicated PackageNameConfig.cmake files that you'll find pretty much everywhere these days, not the old FindPackage.cmake modules.

gabereiser 4y ago

Exactly my thoughts. We can do better than both these solutions but it's going to take an industry to adopt the practice. I like what vcpkg is doing... I'm a cmake guy myself, but I always found pkg-config to be useful to the point where you're upset when it's not present and that presents a problem. Build chains need consistency, reproducibility, and some form of order.

albertzeyer 4y ago

What's the problem with pkg-config? You mean the slightly inconsistent behavior across those different implementations? Are they really relevant in practice? I never really had problems with it.

mananaysiempre 4y ago

AFAICT to use CMake for dependency discovery you have to either be or require CMake, the full interdependent coupling of a macro language and half-of-a build tool. Regardless of the merits of either part, that’s a lot to implement and a lot to commit to. Pkg-config, on the other hand, is rather small. The initial implementation was bulky enough to annoy people into at least two rewrites, but the concepts are few and the requirements on the host build system practically nonexistent. (One place where the CMake-like approach won is the editable form of scientific documents. I like TeX to bits, but you can’t even tokenize it without being TeX, and even if you are essentially the only operation you can do on it is typeset, those even feed into each other. Thus the current two decades of half-working AST-producing parsers and ugly HTML generators and DVI extractors and whatnot.) So, no, I’m not the least bit sad CMake didn’t win the game, not any more than I’m sad autom4te didn’t. Pkg-config isn’t ideal, but as far as not forcing the whole world into its image it’s miles better.

jcelerier 4y ago
> Pkg-config, on the other hand, is rather small. The initial implementation was bulky enough to annoy people into at least two rewrites, but the concepts are few and the requirements on the host build system practically nonexistent. yet all these years and it's still a pain on Windows with the Visual Studio world. And if it doesn't work with VS (as in, you can have a VS solution which uses pkg-config automatically to find libraries / flags / ... without having to fudge with scripting it yourself) it's 100% irrelevant to any cross-platform discussion (and thus most of C / C++ / native ... software development).
- mananaysiempre 4y ago
  There’s “builds on Windows” cross-platform and there’s “works on a big-endian MIPS router with a 2.6.x series Linux kernel and an ancient Busybox” cross-platform. And a lot more. All of those are important to somebody. So “100% irrelevant to any cross-platform discussion” for lack of Windows support sounds overexaggerated to me, let alone for lack of Visual Studio support. Also, well. Before the article under discussion, there was no decent Windows support, because no pkg-config user was willing to donate their time or spend their money to improve the Microsoft Windows ecosystem. Now somebody came around and there is. Perhaps that will happen to the Microsoft Visual Studio ecosystem as well, in time, or perhaps not. Probably not going to be me, though. (In the case of CMake, the support appeared when Microsoft spent their money on improving the Microsoft Visual Studio ecosystem, because C++ programmers not using Visual Studio became numerous enough, and CMake became popular enough among them, that not being to interoperate with their work diminished the IDE’s value. I don’t see that happening with pkg-config, mainly because a lot of its usage is in the C world, and Microsoft doesn’t really care all that much about that.)

tialaramex 4y ago

> to paraphrase Stroustrup: there are only two kinds of tools, the ones people complain about and the ones nobody uses. Yeah, no, one of the interesting things is that we routinely use some tools without even really thinking about them - we don't complain about them because we never think of them at all even though we're using them, they're that unobtrusive. In its original context Bjarne's claim is belied by the StackOverflow surveys. You can choose to imagine that "nobody uses" Rust, which famously keeps topping the charts, but not far down the list is Python. It would be nice if our industry could manage better than .pc files but I'm an old man and when I wrote all my early code this didn't exist, your best chance was to cargo cult some auto-detection of common libraries.