U-config – A new, lean pkg-config clone
nullprogram.com
U-config – A new, lean pkg-config clone
1–10 of 53 posts
Re: U-config – A new, lean pkg-config clone
#2I love to see slim alternatives to bigger, older tools (acknowledging that both versions have their place in the world).
However, I have to ask: why C? Apparently the author is very comfortable using it, and I'm sure using C has enabled them to make a very efficient implementation with a small binary size.
But this program is just slinging around strings, right? Is manual memory management actually important, or even desirable?
Re: U-config – A new, lean pkg-config clone
#3I 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.
Re: U-config – A new, lean pkg-config clone
#4I 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?
Re: U-config – A new, lean pkg-config clone
#5I 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…
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.
Re: U-config – A new, lean pkg-config clone
#6I 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…
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.
Re: U-config – A new, lean pkg-config clone
#7I 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…
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.
Re: U-config – A new, lean pkg-config clone
#8I 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 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.
Re: U-config – A new, lean pkg-config clone
#9I'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?id=98215
[2] https://lists.freedesktop.org/archives/pkg-config/2018-May/0...
Re: U-config – A new, lean pkg-config clone
#10I love to see slim alternatives to bigger, older tools (acknowledging that both versions have their place in the world). However, I have to ask: why C? Apparently the author is very comfortable using it, and I'm sure using C has enabled them to make a very efficient implementation with a small binary size. But this program is just slinging around strings, right? Is manual memory management actually important, or even…
Rust would have been a better option. But probably it's just because the author is more familiar with C. Maybe also because the author wants it to be more cross platform.