ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
hasen_judy has quit [Remote host closed the connection]
dimenus has quit [Read error: Connection reset by peer]
<andrewrk>
Dimenus, HKLM\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows has 2 properties
<dimenus>
andrewrk: what version of MSVC do you have installed on that laptop?
<dimenus>
I'm using MSVC 2017 / Win10 / Windows SDK 10
<dimenus>
the v10.0 key contains a valid path to the tree which contains kernel32.lib
hasen_judy has quit [Remote host closed the connection]
<andrewrk>
dimenus, MSVC 2015
<andrewrk>
Win10
<dimenus>
Do you have either the Windows 8 or Windows 10 sdks installed?
<andrewrk>
I didn't explicitly install a windows SDK
<dimenus>
ok
<andrewrk>
it must have come with msvc 2015 or with windows update
<dimenus>
Microsoft completely changed the installer with 2017
<dimenus>
and there's a lot less bloat now
<dimenus>
I'm thinking this key will work for someone who has 8.1 / 10 installed: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots
<dimenus>
But I need to do a procmon trace on an older version to determine what previous versions of visual studio do for kernel32
<dimenus>
or should I just go with 8.1/10 for now?
ofelas has joined #zig
<andrewrk>
dimenus, I don't think I fully understand your question
<dimenus>
sorry, probably misusing irc. I'm just thinking out loud.
<andrewrk>
feel free to think out loud
<dimenus>
I need to fire up my Win7 vm to find where kernel32 comes from on an older setup
<andrewrk>
I'm at work again without my windows laptop
<dimenus>
Do you use a mac in the office?
<andrewrk>
linux
<andrewrk>
dimenus, one idea we could have, is the compiler can have a configuration file and state
<andrewrk>
and you could do something like
<andrewrk>
zig find-libc e:\
<andrewrk>
and it will scan e:\ looking for msvc installations. it could find any number of them
<andrewrk>
zig list-libc
<andrewrk>
prints all the libcs it knows about, with '*' next to the "default" one
<andrewrk>
we can use the registry (do we need com? maybe not?) to seed the list initially
Andris_zbx has quit [Remote host closed the connection]
<andrewrk>
zig select-libc 3
<andrewrk>
(where 3 is the 3rd libc listed from zig list-libc)
<andrewrk>
this would be for native builds only. for cross-compile builds you always have to give the path to libc explicitly (but maybe you could use one of the ones from the list)
<dimenus>
COM is preferred for the newest versions according to Microsoft (they actually include a nuget package which I'm trying to avoid at all costs)
<andrewrk>
what docs are you looking at that says COM is preferred?
<dimenus>
but the registry keys are not consistent across versions, MS has changed them several times
<dimenus>
CMAKE and Rust both use the COM interface for 2017
<andrewrk>
good to know
<andrewrk>
sounds like that's how we should do it
<dimenus>
i do like the option of having the compiler be able to list the instances it finds
Benq has quit [Ping timeout: 260 seconds]
ofelas has quit [Quit: shutdown -h now]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
<andrewrk>
dimenus, you know what it should be, actually. we should have an environment variable ZIG_LIBC_SEARCH_PATHS
<andrewrk>
and if we had a find-libc utility, it would only help find a path
<andrewrk>
it wouldn't change any state in a conf file
<dimenus>
written in Zig? :)
<andrewrk>
but of course :)
<dimenus>
well, that would be the goal anyway
<andrewrk>
I mean I think it would just be a subcommand of the compiler
<andrewrk>
which will eventually be self hosted
<andrewrk>
we can start now, by the way. I decided how the self-hosting will work
<andrewrk>
we will always have the c++ compiler, forever, in the repo. and it has to be able to build the zig compiler.
<andrewrk>
*build the self hosted compiler
<dimenus>
just making sure I understand this correctly, the subcommand would invoke a separate tool, correct?
<andrewrk>
I don't see a reason to put it in a different binary
<andrewrk>
so the build process is: 1. compile c++ source code into zig1 compiler. 2. compile zig source code with zig1 compiler into zig2 compiler. 3. compile zig source code with zig2 compiler into zig3 compiler. zig3 compiler is the final binary
<andrewrk>
it's 3 steps but it never grows beyond 3
<dimenus>
what's the technical reason we need zig3?
<andrewrk>
to be clear the binary will still be called "zig". I'm using zig3 to distinguish for the purposes of explaining the self hosting process. but why we need it:
<dimenus>
ok, so I'll put the code to find libc/kernel32 in a separate cpp file rather than in-line within analyze.cpp
<andrewrk>
zig1 is the output of c++ code. zig2 is the output of zig1 compiling zig code. zig2 is built using a different codebase than zig1
<dimenus>
ah that makes sense
<andrewrk>
so the c++ compiler can have bugs, that's fine, as long as it can produce a zig compiler that can produce a zig compiler that passes all the tests and doesn't have bugs :)
<andrewrk>
dimenus, the libc-finding code written in c++ is not wasted, because we always will link with LLVM and clang, which means that we have to link libc, which means we have to find msvc in the c++ compiler
achamb has quit [Ping timeout: 240 seconds]
<andrewrk>
although, we could use the cmake build tools to find msvc and pass that to the next step. hm.
<andrewrk>
anyway whatever effort you do is not wasted because if it's solved in c++ it's easy to translate to zig later