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

21–30 of 53 posts

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

#21

Post by unwind »

Very nice, and I liked the detailed description of implementation choices. A bunch of which I personally wouldn't agree with (of course) but that's programming for you. :)

As a minor detail, even as a long time computer user of the technical kind, I found it difficult to distinguish between "pkgconfig" and "pkg-config" as being two separate things throughout the text, probably since the dash is silent when I pronounce these words. Not sure how to fix it, perhaps by actually making the names longer ("the Freedesktop pkgconfig" and "pkgconfig.org" for instance).

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

#22

Post by mort96 »

qbasic_forever wrote: post #20
mort96 wrote: post #17

Earlier quoted context omitted.

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

The maintainers' time is valuable, yes, which is why it's good to have a system where they can get to something in their own time that doesn't rely on contributors spamming on a mailing list.

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

#23

Post by mariusor »

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…

Chris mentions explicitly that he used a byte buffer plus length pair backed by an arena allocator for the strings in the application.

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

#24

Post by mort96 »

Galanwe wrote: post #5
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…

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.

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

#25

Post by jcarrano »

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…

ANSI-C (and to a lesser extent C99) is pretty much the only language which you can compile anywhere, forever. For this project portability is the #1 requirement.

If he used, say Rust, then the target system needs a rust compiler, and furthermore, the language is not even close to being as standardized a C is at the moment, i.e. who knows if in the future you will still be able to compile your program that you write on 2023's dialect?

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

#26

Post by aseipp »

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…

I used email workflows before. And on a project I used to work on (Glasgow Haskell Compiler), people would originally just attach .patch files to issues in the bug tracker we used, called Trac. This was how it worked for years, and while it did work, it had some similar outcomes: tons of patches that just silently were forgotten. The only saving grace is that I had a search macro setup that could just find "WITH attachment AND status = 'Ready for Review'" but of course that requires people knowing to fill out the forms properly to specify that this issue has a patch and that it fixes the problem and it's ready for review. Why would someone who spent 2 hours writing a bugfix know this? In contrast I have hundreds of hours in this realm so it's second nature. But it's a joke to think it's intimately or immediately familiar.

Occasionally someone would email me and ask to look at a patch and ask if they did something wrong, which is why it got ignored. Ignoring any actual technical complaints, probably 80% of the time my answer was "Actually, I just missed this one" or "It didn't have the "patch" field set so my search didn't find it." I had to do this annoyingly often; it was annoying. I didn't blame anyone for it however. But pretending it's not annoying is also a lie.

Honestly I don't think GitHub is the end-all of project contribution and it still has some really annoying flaws. I don't like the branch-merge workflow; I prefer non-branch-based merge workflows, which email does provide. But beyond that there are almost no advantages to it in my experience.

I also suspect that there's a reinforcement mechanism going on these days. People who think email is good for this task already love email. They think it's amazing. In some sense I can agree, and in the past, it really was amazing. But less and less people even "bother" with email in my experience than ever before; to them, it's a necessary evil where they get shit shoveled at them 24/7/365, all so that they can pluck a single piece of information from the shitheap of trash; where they can go to reset their account passwords. It is not a bright shining feature of the internet to them.

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

#27

Post by synergy20 »

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

for one thing, pkg-config really should do -isystem instead of -I for headers, -isystem helps editor to not bother checking them for syntax conformity, otherwise my vi sometimes produces thousands of lines of warnings for those standard header files, and I have to add isystem to them manually. cmake smartly converts pkg-config's -I to -isystem nowadays, which is great.

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

#28

Post by synergy20 »

Galanwe wrote: post #5
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…

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 actually 'fixes' weakness in pkg-config for me, e.g. converting -I to -isystem, big deal for me at least.

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

#30

Post by phoebos »

unwind wrote: post #21

Very nice, and I liked the detailed description of implementation choices. A bunch of which I personally wouldn't agree with (of course) but that's programming for you. :) As a minor detail, even as a long time computer user of the technical kind, I found it difficult to distinguish between "pkgconfig" and "pkg-config" as being two separate things throughout the text, probably since the dash is silent when I pronounc…

The separate tools you're probably thinking of are `pkgconf` and `pkg-config`.
Post reply on HN