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

41–50 of 53 posts

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

#41

Post by mananaysiempre »

gabereiser wrote: post #7
Galanwe wrote: post #5

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

CMake-generated Makefiles call CMake at build time—unlike autotools where m4 and Perl are not required once you’ve built the distribution tarball. If you really really want, with autoconf alone you can even write the config.h by hand, the template contains lists all the defines that should go there. (With automake added to the mix, you probably can’t.)

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

#42

Post by saurik »

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

I mean, it might not be "completely ignored", but after the initial triage by a maintainer I have definitely experienced extremely large projects going years ignoring something from the core while occasionally random third parties show up to cry. The worst part is that if people stop actively commenting with "me too"--even if an official developer chastises them for it every time--the issue often gets auto-locked/deleted. (Or, in the case of a pull request, the code will rot to the point where something auto-closes it due to it no longer merging.)

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

#43

Post by saurik »

synergy20 wrote: post #27
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.

That really seems like it should be the purview of the build system (such as cmake), not pkg-config. The flags provided by pkg-config should be as simple and obvious and easy to reason about and as portable as possible (and, worst case, as consistent as possible so you can convert it to some different flag format, as arguably is being done there by cmake). The goal of -isystem has nothing to do with syntax highlighting, even if your text editor may also be reading it (though I am unsure from where, lol)... it has non-trivial effects on things like #include path ordering.

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

#44

Post by saurik »

jcelerier wrote: post #34
mananaysiempre wrote: post #13

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

If you are serious about cross-platform, the answer is simple, and has been the same for decades: don't use Visual Studio to build for Windows, as it isn't offering you anything of value. This answer used to be maybe a bit controversial--hell: I even supported Visual Studio for years back in the early '00s--but now even Chrome builds with clang... if it is good enough for Chrome, it is good enough for you.

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

#45

Post by saurik »

mathstuf wrote: post #32
nerdponx wrote: post #4

Earlier quoted context omitted.

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

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?

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

#46

Post by arp242 »

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…

pkg-config hardly has "thousands of people demanding time and attention". It doesn't seem to require that much attention.

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

#47

Post by arp242 »

jcarrano wrote: post #25
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 o…

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.

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

#48

Post by phoebos »

arp242 wrote: post #47
jcarrano wrote: post #25

Earlier quoted context omitted.

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

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.

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.

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

#49

Post by Lammy »

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

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

#50

Post by aldonius »

albertzeyer wrote: post #10
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…

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.

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.

Post reply on HN