in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions.
-
in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions. since it is not strictly about -I and -L he calls it "broken".
and, if that were the case, sysroot would be a lot easier.
the whole problem is that ${pc_sysrootdir} was added quietly much later, and so most .pc files have no awareness of ${pc_sysrootdir}.
the original idea was that you would have `prefix=${pc_sysrootdir}%PREFIX%` in your foo.pc.in file, but basically nobody does this. because they copy other .pc files usually.
meanwhile we need to support sysroot.
so pkgconf classic (< 2.0) just automatically mutated -I and -L paths (and some others) as expected when ${pc_sysrootdir} is not used.
but clever workarounds result in new ways to break the system.
remember how i said the intended way to use ${pc_sysrootdir} was to augment ${prefix} with it and make all other paths relative to ${prefix}? (this also makes --define-prefix work meaningfully on windows) well... some pc files do not do that, and instead do things like
```
prefix=/usr
includedir=${pc_sysrootdir}/${prefix}/include
```we used to have a complicated set of heuristics to detect this specific type of mistake. in pkgconf 3 we have moved to bytecode-based string substitution, and have given ${pc_sysrootdir} its own special opcode. this allows us to just look and see if the ${pc_sysrootdir} opcode has ever been encountered. we can then selectively apply mitigations.
anyway. back to the -I and -L thing. it sure would be nice if that was the case, but it isn't. sometimes (gstreamer comes to mind) you need to install new things into the sysroot because there are headers that need to be installed in a special place relative to the sysroot.
what does this mean? it means that --variable also has to be supported. and at that point, you may as well just support it everywhere.
i would again like to stop hearing about this completely broken pkg-config implementation.
projects like meson should mark it as broken instead of wasting their time negotiating with a techbro.
-
in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions. since it is not strictly about -I and -L he calls it "broken".
and, if that were the case, sysroot would be a lot easier.
the whole problem is that ${pc_sysrootdir} was added quietly much later, and so most .pc files have no awareness of ${pc_sysrootdir}.
the original idea was that you would have `prefix=${pc_sysrootdir}%PREFIX%` in your foo.pc.in file, but basically nobody does this. because they copy other .pc files usually.
meanwhile we need to support sysroot.
so pkgconf classic (< 2.0) just automatically mutated -I and -L paths (and some others) as expected when ${pc_sysrootdir} is not used.
but clever workarounds result in new ways to break the system.
remember how i said the intended way to use ${pc_sysrootdir} was to augment ${prefix} with it and make all other paths relative to ${prefix}? (this also makes --define-prefix work meaningfully on windows) well... some pc files do not do that, and instead do things like
```
prefix=/usr
includedir=${pc_sysrootdir}/${prefix}/include
```we used to have a complicated set of heuristics to detect this specific type of mistake. in pkgconf 3 we have moved to bytecode-based string substitution, and have given ${pc_sysrootdir} its own special opcode. this allows us to just look and see if the ${pc_sysrootdir} opcode has ever been encountered. we can then selectively apply mitigations.
anyway. back to the -I and -L thing. it sure would be nice if that was the case, but it isn't. sometimes (gstreamer comes to mind) you need to install new things into the sysroot because there are headers that need to be installed in a special place relative to the sysroot.
what does this mean? it means that --variable also has to be supported. and at that point, you may as well just support it everywhere.
i would again like to stop hearing about this completely broken pkg-config implementation.
projects like meson should mark it as broken instead of wasting their time negotiating with a techbro.
some idiot wanting to turn pc files into an ISO standard because of fucking u-config, i wish this project would just utterly fuck off
-
some idiot wanting to turn pc files into an ISO standard because of fucking u-config, i wish this project would just utterly fuck off
to be blunt: any opportunity for friendly collaboration with or concerning u-config ended when i was forced to respond to casually dropping security vulnerabilities in the u-config maintainer's blog where he goes on and on about how much of an elite coder he is
-
in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions. since it is not strictly about -I and -L he calls it "broken".
and, if that were the case, sysroot would be a lot easier.
the whole problem is that ${pc_sysrootdir} was added quietly much later, and so most .pc files have no awareness of ${pc_sysrootdir}.
the original idea was that you would have `prefix=${pc_sysrootdir}%PREFIX%` in your foo.pc.in file, but basically nobody does this. because they copy other .pc files usually.
meanwhile we need to support sysroot.
so pkgconf classic (< 2.0) just automatically mutated -I and -L paths (and some others) as expected when ${pc_sysrootdir} is not used.
but clever workarounds result in new ways to break the system.
remember how i said the intended way to use ${pc_sysrootdir} was to augment ${prefix} with it and make all other paths relative to ${prefix}? (this also makes --define-prefix work meaningfully on windows) well... some pc files do not do that, and instead do things like
```
prefix=/usr
includedir=${pc_sysrootdir}/${prefix}/include
```we used to have a complicated set of heuristics to detect this specific type of mistake. in pkgconf 3 we have moved to bytecode-based string substitution, and have given ${pc_sysrootdir} its own special opcode. this allows us to just look and see if the ${pc_sysrootdir} opcode has ever been encountered. we can then selectively apply mitigations.
anyway. back to the -I and -L thing. it sure would be nice if that was the case, but it isn't. sometimes (gstreamer comes to mind) you need to install new things into the sysroot because there are headers that need to be installed in a special place relative to the sysroot.
what does this mean? it means that --variable also has to be supported. and at that point, you may as well just support it everywhere.
i would again like to stop hearing about this completely broken pkg-config implementation.
projects like meson should mark it as broken instead of wasting their time negotiating with a techbro.
@ariadne i don't have useful technical input here because my knowledge is way out of date, but as someone who was cross-compiling dozens and dozens of packages as far back as 2012 and getting absolutely bodied by pkgconfig sysroot issues, i just want to thank you for trying to deal with it at the very least
-
@ariadne i don't have useful technical input here because my knowledge is way out of date, but as someone who was cross-compiling dozens and dozens of packages as far back as 2012 and getting absolutely bodied by pkgconfig sysroot issues, i just want to thank you for trying to deal with it at the very least
@whitequark this was the motive. everything pkgconf does that is weird in whatever way probably has a trail of blood leading to the underlying decision. i built it to simplify alpine's bootstrap.
-
to be blunt: any opportunity for friendly collaboration with or concerning u-config ended when i was forced to respond to casually dropping security vulnerabilities in the u-config maintainer's blog where he goes on and on about how much of an elite coder he is
that blog, incidentally, continues to piss me off.
shitting on others to elevate yourself is a classical trait of narcissistic behavior and all it does is hurt the people you are shitting on.
i'm so sorry that when i originally wrote pkgconf i was not even a professional software engineer or had ever even heard of hacker news for that matter. instead, it was a hobby thing: i wanted to make the operating system i use better.
so when i saw strlcpy and strlcat used in a bunch of other FOSS projects, I said "well everyone else is using this, it's probably good enough!"
and, no, it's not good enough. but the version of me that knows that has had 15 years of experience working in tech, and the version of me that decided to use strlcpy was being shot at every day because i had to take methheads' kids away for a living.
-
that blog, incidentally, continues to piss me off.
shitting on others to elevate yourself is a classical trait of narcissistic behavior and all it does is hurt the people you are shitting on.
i'm so sorry that when i originally wrote pkgconf i was not even a professional software engineer or had ever even heard of hacker news for that matter. instead, it was a hobby thing: i wanted to make the operating system i use better.
so when i saw strlcpy and strlcat used in a bunch of other FOSS projects, I said "well everyone else is using this, it's probably good enough!"
and, no, it's not good enough. but the version of me that knows that has had 15 years of experience working in tech, and the version of me that decided to use strlcpy was being shot at every day because i had to take methheads' kids away for a living.
@ariadne
This is something that frustrates me: programming - in any language or system- is full of bad old footguns, still documented, still with usage examples and example code, that you're just supposed to know about.Beginners don't stand a chance to do the right thing. An already complicated and frustrating experience just got even worse, with community judgement as a stinky cherry on top. It's amazing anyone at all willingly stick with this.
-
that blog, incidentally, continues to piss me off.
shitting on others to elevate yourself is a classical trait of narcissistic behavior and all it does is hurt the people you are shitting on.
i'm so sorry that when i originally wrote pkgconf i was not even a professional software engineer or had ever even heard of hacker news for that matter. instead, it was a hobby thing: i wanted to make the operating system i use better.
so when i saw strlcpy and strlcat used in a bunch of other FOSS projects, I said "well everyone else is using this, it's probably good enough!"
and, no, it's not good enough. but the version of me that knows that has had 15 years of experience working in tech, and the version of me that decided to use strlcpy was being shot at every day because i had to take methheads' kids away for a living.
and like, that's the thing that kinda frustrates me about the state of FOSS today. but i am also hopeful at the same time.
there were two basic responses to his blog (which is still up as of this posting several years later). most people ignored it, but some people have attached themselves to this project because it has demoscene-level hobby coding in it (which is impressive, but also inappropriate for a tool like pkg-config).
i'm sorry that it is shiny, but we need to show some solidarity here. we should not tolerate people who promote their work by shitting on others.
-
and like, that's the thing that kinda frustrates me about the state of FOSS today. but i am also hopeful at the same time.
there were two basic responses to his blog (which is still up as of this posting several years later). most people ignored it, but some people have attached themselves to this project because it has demoscene-level hobby coding in it (which is impressive, but also inappropriate for a tool like pkg-config).
i'm sorry that it is shiny, but we need to show some solidarity here. we should not tolerate people who promote their work by shitting on others.
but back to the ISO thing for a moment.
why on earth would *I* want to pursue ISO standardization of pc(5) files?
what is the benefit to the pkgconf agenda?
there is none. it only serves to freeze a bad file format rather than fix it.
-
but back to the ISO thing for a moment.
why on earth would *I* want to pursue ISO standardization of pc(5) files?
what is the benefit to the pkgconf agenda?
there is none. it only serves to freeze a bad file format rather than fix it.
the pkgconf agenda, for the record, is to:
- improve the pc(5) format so that it is more aligned with the needs of modern build systems
- introduce new ways of leveraging pc(5) data, e.g. SBOM generation -
the pkgconf agenda, for the record, is to:
- improve the pc(5) format so that it is more aligned with the needs of modern build systems
- introduce new ways of leveraging pc(5) data, e.g. SBOM generationwhat i will absolutely say is if you care about the health of the pkg-config ecosystem, you should reject u-config on the simple grounds that the maintainer only built u-config with the goal of deprecating the entire pkg-config ecosystem
-
what i will absolutely say is if you care about the health of the pkg-config ecosystem, you should reject u-config on the simple grounds that the maintainer only built u-config with the goal of deprecating the entire pkg-config ecosystem
@ariadne and I guess given the windows background, it has the potential of being as awful as the stuff cmake came up with -
what i will absolutely say is if you care about the health of the pkg-config ecosystem, you should reject u-config on the simple grounds that the maintainer only built u-config with the goal of deprecating the entire pkg-config ecosystem
@ariadne TIL about u-config, and... it looks terrible. Why would anyone consider it to be reasonable?
-
@ariadne and I guess given the windows background, it has the potential of being as awful as the stuff cmake came up with
@lanodan it's okay, pkgconf now has higher quality windows support than u-config
-
@lanodan it's okay, pkgconf now has higher quality windows support than u-config
@ariadne Yeah, hopefully windows dev will get the memo… -
@ariadne TIL about u-config, and... it looks terrible. Why would anyone consider it to be reasonable?
@neal i do not know. yet people keep sending me emails about it from time to time.
i would have thought the fact that i banned both skeeto and NRK from the pkgconf github org should speak for itself about my views on collaborating with them, but apparently not!
-
what i will absolutely say is if you care about the health of the pkg-config ecosystem, you should reject u-config on the simple grounds that the maintainer only built u-config with the goal of deprecating the entire pkg-config ecosystem
anyway, basically everything in pkgconf is the way it is because doing it some other way caused distribution-scale breakage
-
and like, that's the thing that kinda frustrates me about the state of FOSS today. but i am also hopeful at the same time.
there were two basic responses to his blog (which is still up as of this posting several years later). most people ignored it, but some people have attached themselves to this project because it has demoscene-level hobby coding in it (which is impressive, but also inappropriate for a tool like pkg-config).
i'm sorry that it is shiny, but we need to show some solidarity here. we should not tolerate people who promote their work by shitting on others.
@ariadne I'm curious about which coding techniques you find impressive but inappropriate for this kind of tool.
To be clear, I don't mean to defend u-config, and I agree that we shouldn't tolerate people who promote their work by shitting on others.
-
@ariadne I'm curious about which coding techniques you find impressive but inappropriate for this kind of tool.
To be clear, I don't mean to defend u-config, and I agree that we shouldn't tolerate people who promote their work by shitting on others.
@matt i think tools like this should be as boring as possible. they should properly use libc rather than inventing their own.
-
@matt i think tools like this should be as boring as possible. they should properly use libc rather than inventing their own.
@ariadne Yeah. I understand the urge to fight the bloat of modern software by going far in the other direction, to the point of having a version that makes Linux syscalls directly and requires no libc; that's an impressive stunt. But it probably isn't good for the maintainability of the tool.
