<farkuhar> emmett1: I'm still investigating why aliases and `prt-get dependent` do not work when compiled on a system without gcc. The connection between those two features is more obvious if the latter was originally implemented using an external dependency map, only later rewritten to scan Pkgfiles directly.
<farkuhar> So I'm looking for code that generates an intermediate representation of the Pkgfile data, in the same format as prt-get.aliases, which then gets passed to a string handler to create a map. But the string handler must be relying on GNU extensions, if it breaks on a system where clang is your only C++ compiler.
<farkuhar> It's a shame that chinarulezzz doesn't hang out in these channels any more. He's one of the last devs to have immersed himself deeply in the prt-get source code.
<SiFuh__> farkuhar: He left because of beerman
<farkuhar> It does make sense to reuse the code that parses prt-get.aliases, because in both operations you want to return the name on the left side of the colon, for each line where the argument appears in the list of dependencies (or the list of ports that an alias can satisfy).
<farkuhar> Note that emmett1 did not report breakage of `prt-get depends` (or quickdep or deptree) on a system without gcc. Reading the external dependency map in the forward direction (from left side of the colon to the right side) has no counterpart when looking up aliases, so there's no code reuse for those operations.
<farkuhar> I'm guessing the different behaviours, with vs without gcc, stem from slightly different interfaces provided by system headers <string>, <utility>, <map>, <vector>, and <list>. The next step would be to compare the llvm/clang headers against those provided by gcc.
<SiFuh__> See if I can get an answer for jaeger. Because what is the point of having MUSL to slim a system down if we are just going to have bloat in core anyway. I'd like to see quite a few core ports shifted to opt.
<SiFuh__> for/from
<farkuhar> I was under the impression that meson or cmake (two of the more popular build systems these days) has python3 as a dependency, so a core system cannot be bootstrapped using just gcc/binutils and autotools.
<SiFuh__> farkuhar: Well you could have answered me in CRUX-Social then when I asked twice. Instead of turning me into a fool in CRUX ;-)
<farkuhar> SiFuh__: According to the topic in #crux-social, it's not supposed to be used for serious discussion. I made an exception for the python3 footprints, only because zorz hadn't yet found his way in here.
<farkuhar> I seem to remember somebody scolding me for spamming the #crux-social channel with MUSL-related questions. Now that we have a dedicated channel for that, the social channel can go back to its former identity as the place for irrelevant digressions.
<SiFuh__> farkuhar: It wasn't it was just basic conversation. Strictly ignoring others to spam the channel with a flood of MUSL content is just freaking annoying. That is the reason why crux-musl exists now.
<SiFuh__> I said before. Nothing worse that talking to zorz. But then there is. Talking to zorz, going away to see you flooded the channel with so much MUSL shit, it has completely surpassed the character and line limit of my irssi client so now I need to open the log file .irssi/logs/Libera/\#crux-social.log to see if zorz replied to me. Usually not and so much time is wasted.
<dlcusa> Another reason for #crux-musl is to get all crux-musl discussion in one channel for ease of future searching.
<SiFuh__> dlcusa: yes. Not that I search farkuhar's MUSL stuff. He kind of goes way overboard with massive paragraphs.
<dlcusa> Still, you should value being able to reference them as needed.
<farkuhar> `comm -12 <(ls /usr/ports/core) <(prt-get dependent --recursive python3 |sort)` would also have answered SiFuh__s question, unless his prt-get was compiled on a system without gcc, thereby breaking the `dependent` command.
<SiFuh__> farkuhar: Actually I found out I was wrong. Core ports have dependency lines. Not sure if they are accurate though.
<SiFuh__> Its non-core ports that shouldn't reference core ports.
<farkuhar> Actually our only report of breakage is on a system where gcc has been replaced by llvm/clang. Who knows what might happen if we followed remiliascarlet's suggestion and replaced gcc with tcc?