5 ms·

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

71 points by phoebos 4y ago

nerdponx 4y ago
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 desirable?
- stabbles 4y ago
  Because of bootstrapping
- albertzeyer 4y ago
  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.
  - aldonius 4y ago
    I'm a big Rust fan in the sense that it's the language I go to nowadays to write anything serious. But it's quite a lot in terms of bootstrapping. Whereas this? Just the very basics, fully portable, pretty much any C compiler has you covered.
- phoebos 4y ago
  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.
- pmarin 4y ago
  He implemented this alternative explicitly to be included on his own C Windows development environment, w64devkit.
- hobo_mark 4y ago
  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.
- mariusor 4y ago
  Chris mentions explicitly that he used a byte buffer plus length pair backed by an arena allocator for the strings in the application.
- jcarrano 4y ago
  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?
  - arp242 4y ago
    Lua is pretty small, portable, and easy to build; you can ship the lua source code with a "lua-pkg-config" so you don't need to install anything else. Lua is not my favourite language, but for something like this it might be a nice fit. I think C is also fine though.
    - phoebos 4y ago
      Yes, the official Lua implementation is written in a very widely supported subset of C, so is probably one of the most portable languages along with C. Lua might well be a bit more concise for a task like this string processing, but in such as case it's just syntactic sugar really. The C is uncomplicated and efficient.
nickelpro 4y ago
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
marcodiego 4y ago
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/-/commit/c53385b5dbd25844faa89b1c8297d61ab05ed6ef https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commi... https://bugs.freedesktop.org/show_bug.cgi?id=98215 https://bugs.freedesktop.org/show_bug.cgi?id=98215 [2] https://lists.freedesktop.org/archives/pkg-config/2018-May/001100.html https://lists.freedesktop.org/archives/pkg-config/2018-May/0...
- mort96 4y ago
  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.
  - qbasic_forever 4y ago
    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.
    - mort96 4y ago
stabbles 4y ago
Now imagine a world in which packages provided correct *.pc files that properly supported static linking
pengaru 4y ago
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.
- gooseyard 4y ago
  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.
unwind 4y ago
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).
- phoebos 4y ago
  The separate tools you're probably thinking of are `pkgconf` and `pkg-config`.
sylware 4y ago
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)
- ifreund 4y ago
  (plz read the article, pkgconf is discussed)
  - sylware 4y ago
    (doh! my bad, I did stop at "windows first class...")
Lammy 4y ago
> If a crazy person — or well-known multinational corporation — comes along puts has a space in their system’s installation “prefix”, this .pc will not work. Comedy option: `C:\PROGRA~1` still works as expected on my Win10 box.

71 points by phoebos 4y ago

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

stabbles 4y ago
Because of bootstrapping
albertzeyer 4y ago
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.
- aldonius 4y ago
  I'm a big Rust fan in the sense that it's the language I go to nowadays to write anything serious. But it's quite a lot in terms of bootstrapping. Whereas this? Just the very basics, fully portable, pretty much any C compiler has you covered.
phoebos 4y ago
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.
pmarin 4y ago
He implemented this alternative explicitly to be included on his own C Windows development environment, w64devkit.
hobo_mark 4y ago
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.
mariusor 4y ago
Chris mentions explicitly that he used a byte buffer plus length pair backed by an arena allocator for the strings in the application.
jcarrano 4y ago
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?
- arp242 4y ago
  Lua is pretty small, portable, and easy to build; you can ship the lua source code with a "lua-pkg-config" so you don't need to install anything else. Lua is not my favourite language, but for something like this it might be a nice fit. I think C is also fine though.
  - phoebos 4y ago
    Yes, the official Lua implementation is written in a very widely supported subset of C, so is probably one of the most portable languages along with C. Lua might well be a bit more concise for a task like this string processing, but in such as case it's just syntactic sugar really. The C is uncomplicated and efficient.

nickelpro 4y ago

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

marcodiego 4y ago

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/-/commit/c53385b5dbd25844faa89b1c8297d61ab05ed6ef https://gitlab.freedesktop.org/pkg-config/pkg-config/-/commi... https://bugs.freedesktop.org/show_bug.cgi?id=98215 https://bugs.freedesktop.org/show_bug.cgi?id=98215 [2] https://lists.freedesktop.org/archives/pkg-config/2018-May/001100.html https://lists.freedesktop.org/archives/pkg-config/2018-May/0...

mort96 4y ago
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.
- qbasic_forever 4y ago
  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.
  - mort96 4y ago

stabbles 4y ago

Now imagine a world in which packages provided correct *.pc files that properly supported static linking

pengaru 4y ago

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.

gooseyard 4y ago
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.

unwind 4y ago

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).

phoebos 4y ago
The separate tools you're probably thinking of are `pkgconf` and `pkg-config`.

sylware 4y ago

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)

ifreund 4y ago
(plz read the article, pkgconf is discussed)
- sylware 4y ago
  (doh! my bad, I did stop at "windows first class...")

Lammy 4y ago

> If a crazy person — or well-known multinational corporation — comes along puts has a space in their system’s installation “prefix”, this .pc will not work. Comedy option: `C:\PROGRA~1` still works as expected on my Win10 box.