<scientes>
ok, i found the thing that was crashing llvm
<scientes>
the builtin patch it ready i think
<scientes>
let the test suite run
<scientes>
I still want to do those implicit casts, but it requires some deeper changes to ir.cpp
<mikdusan>
is there available (to a zig program at runtime) the install location of zig executable?
<andrewrk>
mikdusan, is this in the context of zig build?
<scientes>
mikdusan, on linux you can look at the symlink at /proc/self/exe
<mikdusan>
in context of a test. i’ve had to write a tiny exe for dependency tokenizer so it can be run by a zig testing harness. ie: spawn, feed and read output. but i don’t really want to rely on someone’s PATH to find the test exe.
<mikdusan>
right now i have it landing in same bin as zig… but **only** it was built with cmake option to enable it.
<mikdusan>
scientes: i’m in the “test” and arg0 is a very long zig-cache name.
<andrewrk>
mikdusan, why do you need the zig executable in a unit test?
<mikdusan>
dep_tok is written for stage1 .cpp
<andrewrk>
stage1 .cpp? are you working on a patch for zig?
<andrewrk>
oh this is for dep file parsing
<mikdusan>
issue 2046. nothing big. but it’s different i suppose.
<hryx>
Working on a fix for that fmt regression! whoops *x_x*
<mikdusan>
👍
<hryx>
hey what's up mikdusan
<mikdusan>
just hacking away at a pr. bit by bit.
<hryx>
which one?
<mikdusan>
2046
<hryx>
nice. I've actually been curious about that one because I dunno what "dep file" is referring to
<mikdusan>
zig-cache invokes clang. clang generates like makefile “fragments” .
<hryx>
ah, I see
<mikdusan>
and zig reads them in, and adds those dependency relationships (.c to many .h files) and uses that along with zig-index to be real clever about rebuilding.
<mikdusan>
unfortunately the .d is actually mean to be “make” or “nmake” compatible. we don’t need that, we just need the file names. so have to parse that archiac and somewhat unreliable output.
<hryx>
are you able to implement "just enough" to get those file names? Or is that pretty much writing a fully functional parser
<hryx>
I slightly dread the idea of writing a Makefile parser - even though it seems like a simple format I would not be shocked if there are ambiguities or gotchas
<mikdusan>
i wrote a tokenizer/parser handling a more complicated kind of .d output (because clang forced me to do that for technical reasons).
<mikdusan>
all it does is take TARGET: PREQREQ… and tokenize. but it has to handle spaces, various escapes, line continuations, etc.
<hryx>
oh yeah, I saw that discussion about escapes
<mikdusan>
here’s the mind blowing part. made me laugh:
<mikdusan>
there are 2 output formats. one is easier to tokenize.
<mikdusan>
it uses nmake/jom style quotes around file names. and it’s illegal to have inner/escaped quotes. so pretty straight forward.
<mikdusan>
so when turned on, clang emits that only for PREREQ filenames. the TARGET filename on LHS is still make/compatible.
<mikdusan>
so i have to write a tokenizer for the make/compatible way no matter what.
<hryx>
you mean there are two different string quoting formats on the same line?
<mikdusan>
exactly.
<mikdusan>
so in default format it would do this.
<hryx>
wow COOL feature
<mikdusan>
fo$$o.o: fo$$o.c
<mikdusan>
that’s make/compatible.
<mikdusan>
we turn on nmake/jom for quoting and here’s the output:
<mikdusan>
fo$$.o: “fo$o.c”
<mikdusan>
lol
<hryx>
:<
<hryx>
as they say...
<hryx>
"edge cases matter"
<hryx>
thank you for your service (°_°)7
<hryx>
ok, fmt buggo is fixo
<mikdusan>
do you use vi as your primary editor?
<hryx>
Nej
<hryx>
I'd love to become fluent at vim but have not yet had the commitment to learning
<mikdusan>
i was just going to ask something about vi and fmt . but that’s ok
hio has joined #zig
<hryx>
Not to be a human Hacker News aggregator, but did anyone see Steve Klabnik's (of the Rust team) thoughts on "Free vs. Open Source"?
<hryx>
I don't really like reading blogs, but he seems to be a good writer -- at least enough to convince me that the public concept of open source is still evolving
<andrewrk>
hryx, it made sense to me. I was disappointed he didn't have a proposed solution to the problem he outlined
<hryx>
ha, same... I totally thought he was building up to some proposal, and I was like "ooooh"
<mikdusan>
andrewrk: re: global zig-cache; is it normal and expected that it will accumulate { compiler_rt.o, builtin.zig } for each unique zig (zig id?)