There is already pkgconf: plain and simple C which has the good idea to be independent of the massive glib. (plz use your favorite search engine to find it)
(plz read the article, pkgconf is discussed)
U-config – A new, lean pkg-config clone
31–40 of 53 posts
Re: U-config – A new, lean pkg-config clone
#32I 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…
What's so bad about the format?
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
Re: U-config – A new, lean pkg-config clone
#33Re: U-config – A new, lean pkg-config clone
#34I 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…
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…
> 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).
Re: U-config – A new, lean pkg-config clone
#35Slightly off-topic; One thing pkg-config really needs added is a .pc syntax to say when static linking is unsupported by the package as-installed, which results in `pkg-config --static` invocations for the package returning EXIT_FAILURE so attempts to do so clearly fail without wasting peoples' time. Some distros have been deliberately breaking static linking, but the .pc files and pkg-config on those systems continu…
hah I was going to say the same thing- it's also maddening when a package's autoconf accepts --disable-shared --enable-static and then fails to pass --static to pkg-config.
Re: U-config – A new, lean pkg-config clone
#36Earlier quoted context omitted.
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 diffe…
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.
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
Re: U-config – A new, lean pkg-config clone
#37I've got a few patches in pkg-config[1]. That was the kind of contribution I like to do: small, improves behavior while removing code, very central and popular tool... I gave up contributing after being ignored[2]. Around the same time, other people posting patches to the mailing list were also ignored. Sad. [1] https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commi... https://bugs.freedesktop.org/show_bug.cgi?…
Back in the day, I also posted a bunch of patches to pkg-config, but all of them were ignored by the maintainer(s). I'm not surprised people eventually started creating their own rewrites because the project was very poorly run.
Re: U-config – A new, lean pkg-config clone
#38Earlier quoted context omitted.
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 diffe…
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.
I'm referring to the dedicated PackageNameConfig.cmake files that you'll find pretty much everywhere these days, not the old FindPackage.cmake modules.
Re: U-config – A new, lean pkg-config clone
#39I 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…
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…
Sounds like a similar difference like between make and ninja...
Re: U-config – A new, lean pkg-config clone
#40Earlier quoted context omitted.
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…
> 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 t…
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.)