Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

U-config – A new, lean pkg-config clone

nullprogram.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: U-config – A new, lean pkg-config clone

#11

Post by phoebos »

nerdponx wrote: post #2

I 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…

Everyone and their dog can compile C, and the initial purpose of this project was to get something working on Windows. As you say, this is a relatively uncomplicated program, and there's certainly no need for higher-level features.

Is the only time you choose C when you need manual memory management? I suspect that had nothing to do with their decision.

Re: U-config – A new, lean pkg-config clone

#12

Post by pmarin »

nerdponx wrote: post #2

I 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…

He implemented this alternative explicitly to be included on his own C Windows development environment, w64devkit.

Re: U-config – A new, lean pkg-config clone

#13

Post by mananaysiempre »

nickelpro wrote: post #3

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…

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.

Re: U-config – A new, lean pkg-config clone

#14

Post by pengaru »

Slightly 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 continue to mislead build processes into attempting static builds. Arch in particular has started just silently omitting .a files, even for libraries that have no problem with static linking. It's infuriating if you don't know they've done this and are trusting `pkg-config --static` to Just Work. Arch should be able to stick something in the .pc files for when they've omitted the .a file. As-is it's just producing a broken development environment.

Re: U-config – A new, lean pkg-config clone

#16

Post by stabbles »

nerdponx wrote: post #2

I 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…

Because of bootstrapping

Re: U-config – A new, lean pkg-config clone

#17

Post by mort96 »

marcodiego wrote: post #9

I'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?…

I can't describe how much I hate purely e-mail merge requests. If your e-mail doesn't get a response in a week or so, everyone will have forgotten about it and the relevant people have gotten 1000 new e-mail since yours. With something like gitlab/github/sr.ht/gogs/gitea/anything else, your MR will remain in the relatively short (compared to an inbox with all incoming e-mail) list of open merge requests, clearly visible in a web interface.

Issues you create are the same way.

I very, very rarely experience having my MR or issue completely ignored for years with projects which use a web issue/MR tracker, except for with unmaintained single-person hobby projects. But it seems to be the rule with e-mail, even for actively maintained serious projects.

Re: U-config – A new, lean pkg-config clone

#18

Post by tialaramex »

nickelpro wrote: post #3

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.

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.

Re: U-config – A new, lean pkg-config clone

#19

Post by hobo_mark »

nerdponx wrote: post #2

I 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…

Why anything else? It is a very small tool that is needed to bootstrap a build, C is the lowest common denominator.

Similarly, few things infuriate me more than the installation of some random Python package having to pull an entire Rust toolchain with it.

Re: U-config – A new, lean pkg-config clone

#20

Post by qbasic_forever »

mort96 wrote: post #17
marcodiego wrote: post #9

I'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?…

I can't describe how much I hate purely e-mail merge requests. If your e-mail doesn't get a response in a week or so, everyone will have forgotten about it and the relevant people have gotten 1000 new e-mail since yours. With something like gitlab/github/sr.ht/gogs/gitea/anything else, your MR will remain in the relatively short (compared to an inbox with all incoming e-mail) list of open merge requests, clearly visi…

Email is a fault tolerant communication. If you aren't getting a response then... reply back. If you still aren't getting a response then the community isn't interested at the moment. This is how open source works and how a small collection of maintainers can keep their sanity and avoid burnout in the face of thousands of people demanding time and attention. No one can possibly juggle all of the requests and such like yours. Creating an issue, sending a pull request, etc. costs the maintainer time and that time is incredibly valuable.
Post reply on HN