<marler8997>
andrewrk are you available to discuss tryImport
<andrewrk>
not right now
<andrewrk>
but I would be up for that sometime this week
<marler8997>
well, I think you missed the point on the android example, you said that we would only need to download the android dependency if we need it but that's not the case, build.zig needs the android dependency
<marler8997>
I don't see why you're not getting that
bitmapper has joined #zig
<v0idify>
"drews gonna drew" truth
<g-w1>
andrewrk: while you do the benchmark, could you also commit the formatted results, for consistency?
<andrewrk>
g-w1, no - will do a separate zig fmt commit directly to master branch after this is merged
<andrewrk>
the benchmark is done on already formatted code
<g-w1>
ok, cool, I just like formatted code :)
Snektron has quit [Ping timeout: 264 seconds]
<andrewrk>
marler8997, I can chat on IRC for a bit
<marler8997>
I left another comment about 8 minutes ago
<andrewrk>
catching up on that...
<marler8997>
did you understand that it was build.zig that has a dependency on Android?
<marler8997>
not just the application code?
Snektron has joined #zig
<marler8997>
somewhere in build.zig, there is a @import("androidbuild")
<marler8997>
which provides code to let you configure the build to generate an Android APK
ur5us has quit [Ping timeout: 264 seconds]
<mikdusan1>
psa: llvmorg-12.0.0-rc2 has been tagged
nvmd has quit [Ping timeout: 272 seconds]
<noam>
...already???
<noam>
Wasn't 11 just a few months ago??
<noam>
... have they picked up the pace of version bumping?
nvmd has joined #zig
<mikdusan1>
yeah and 11.1.0 just got tagged. apparently zig builds against it but I didn't have a chance to see if that @reduce aarch64 bug is fixed. 12.x apparently fixes it and their release notes even say reduce builtin is no longer experimental
karchnu has quit [Ping timeout: 256 seconds]
mikdusan1 is now known as mikdusan
<andrewrk>
oof I didn't get a chance to report regressions yet in rc1
<watzon>
andrewrk: curious, how difficult was it to get arbitrary sized integers working in Zig? I just submitted a proposal to have the same thing done in Crystal (since it uses LLVM as well and it should theoretically be possible), but the maintainers have been struggling just getting i128 working properly.
<andrewrk>
marler8997, let's talk about concrete use cases - so what's the example where we have a build.zig that wants to @import("android_sdk") - what is it doing with that import?
<marler8997>
it's configuring the manifest file, adding application identify, etc
<marler8997>
anything that you need to be able to build and Android APK
<marler8997>
a library with all the stuff in ikskuh's talk in his build.zig file
<andrewrk>
I see, so, for example, that package might provide some binaries that optionally want to get executed during `zig build`
<marler8997>
it provides a "linkWithBearSSL" function that adds all the bearssl C sources to the execuatble
marijnfs2 has quit [Ping timeout: 264 seconds]
<marler8997>
I'd like to use it, but without @tryImport I can't
ur5us has joined #zig
<marler8997>
the bearssl example is less of a big deal because download that repo is small, but the same concept applies to Big repositories
marijnfs2 has joined #zig
<marler8997>
by the way andrewrk, I think this is the first time someone has actually asked me a question about this proposal
<andrewrk>
what do you mean?
<andrewrk>
you didn't get any engagement on it before?
<marler8997>
I don't know why some people are immediately passing judgements on this proposal saying things like "I don't like this" when they clearly have not throught about the underlying problem yet
<marler8997>
it's quite frustrating for me to see that behavior
<andrewrk>
yeah that is indeed frustrating
<andrewrk>
unfortunately I think it's one of the phases of getting someone to understand a complex subject - first they deny that it is complex (myself included as guilty of this)
<marler8997>
yeah I think you're right
<marler8997>
this is less of a problem when the problem you're solving is simple
<marler8997>
this one is especially complex because it has so many tendrils in so many other parts of the future of Zig
<andrewrk>
my opinion on this topic is that you're onto a tricky problem that we don't have a complete solution to yet, even planned, and nobody is on your level of understanding yet (myself included), but I do think when I get there I will have something to offer in terms of where we end up landing
<marler8997>
I feel like I can explain it very simply, the messages I sent earlier should explain exactly why @tryImport is necessary
<marler8997>
@tryImport isn't an off the cuff idea I had, I came up to it by logically reducing the problem
<marler8997>
so the question I would first ask you is, are we agreed that projects should be able to use some logic to change their dependencies?
<marler8997>
as opposed to a project's dependencies always being a static non-changing list regardless of the options passed to build.zig
<andrewrk>
for the build artifacts, certainly, but for what build.zig is able to @import, I think we're not quite ready to take that as a shared premise
<marler8997>
gotcha
<marler8997>
so what do you think about the android example then?
<andrewrk>
I need a bit more time to think it through
<marler8997>
ok, then that's probably a good place to leave it
<marler8997>
for now
<marler8997>
but also make sure to consider that dependencies are recursive
<andrewrk>
ok
<marler8997>
and just to be clear, I'm totally happy with alternative solutions, but it is quite frustrating to discuss this with people who don't even seem to be willing to admit it's a problem, nor make a good faith effort to understand the problem
<marler8997>
but I'm telling you right now, I'm pretty confident your package manager idea of a static configuration file is not going to work, and will eventually need to become more complex, and you'll realize it should have been done in Zig, then you're going to want to support packages in your dependencie.zig file, and then you're back to the exact same problem we have today
<andrewrk>
I promise you SpexGuy is making a good faith effort. I think it's a tricky problem to wrap one's head around
<marler8997>
Yeah I definitely agree
<marler8997>
I'm more qualifying what I'm saying in case I say something nasty because my emotions were starting to run high there
<andrewrk>
let's come up with some degenerate example use cases for this problem, and create gists with various projects with interdependencies, that way whatever solution we propose can be evaluated in that context, whether it be @tryImport (which I agree with you solves the stated problem btw) or something else
<andrewrk>
gotta go, lang specs meeting
<marler8997>
andrewrk, yeah that's a good idea because then people can actually understand the problem instead of constatly arguing about whether it is
<g-w1>
it may be helpful to post how the ziget build.zig works with the git prompt and an example of it on the cli so the users fully understand it
ur5us_ has joined #zig
<g-w1>
s/users/people on issue
ur5us has quit [Ping timeout: 264 seconds]
<marler8997>
g-w1, what's your take on this?
xackus has quit [Ping timeout: 240 seconds]
<g-w1>
this is a very complex problem (i may not fully understand yet), your solution looks like reloader with re-execing the binary based on the config
<marler8997>
yeah I mean, that's one solution, but @tryImport can be applied to that idea, or the package-manager idea if we want to separate our dependencies into another file
<g-w1>
My take is that if the compiler, build system, and pm are so intertwined why not have a @needsPackage(comptime name: []const u8, comptime error: []const u8) type that makes a compile error with error if the package is not found, but otherwise returns the package and does all the nessacary reloading for you
<g-w1>
would that solve your usecase?
<g-w1>
basically tryimport but in the language so its less powerful
motiejus has joined #zig
<g-w1>
imo a ?type is SUPER powerful
<marler8997>
yeah that's true
<g-w1>
would that hypothetical builtin solve the use case?
<marler8997>
thinking...
ur5us has joined #zig
<marler8997>
so basically with @needsPackage, it's exactly the same as @import except it lets you provide a custom error message?
<g-w1>
yes
<g-w1>
for example git clone ../ziget ...
<marler8997>
ok, then it doesn't solve the problem becuase we need a way to not get a compile error
<g-w1>
hmm, what if openssl is not found at all, then you need a compile error
ur5us_ has quit [Ping timeout: 246 seconds]
<g-w1>
it will do the reloading for you too
<marler8997>
if (androidEnabled) { if (@tryImport("androidbuildlib")) |abl| { ... } else { ... } }
<g-w1>
what goes in the else? thats what im confused about?
<marler8997>
anything can go there
<marler8997>
it can be a compile error
<marler8997>
but what's important is that this is all wrapped in the if (androidEnabled)
<g-w1>
whats an other usecase for the else?
<g-w1>
besides compileerror
<marler8997>
the else is not the point of it
<marler8997>
the "if (androidEnabled)" is the point
<g-w1>
ok I dont understand it :D, I will try again tommorow
<marler8997>
we only ever enter this block if android is enabled, if android is disabled, our build still works so long as they don't enable android
<marler8997>
and androidEnabled is a runtime known-value
<g-w1>
oh, so tryimport is runtime known?
<marler8997>
come on, I know you can get it
<g-w1>
or comptime but embedded in the binary so it can be known at runtime?
<marler8997>
nope, @tryImport is comptime-known, but we won't know if we actually need it until runtime, which is why we have to handle it being there and not being there
<marler8997>
once you wrap your mind around it, it all makes sense, but it takes a minute
<g-w1>
I think this is a problem that needs a solution. Im not sure if ?type is the best approach, let me come back to you
<marler8997>
?type is the only approach :)
<marler8997>
it has to be ?type because whether or not we need the import depends on a runtime value
<marler8997>
let's compare it to your @needsPackage
<marler8997>
what happens in this example?
<marler8997>
when android is missing, what happens?
<marler8997>
if (androidEnabled) { const abl = @needsPackage("androidbuidlib"); ... }
<marler8997>
stay with me, I feel like you're close to getting this, what happens to this code when androidbuildlib is missing?
<g-w1>
i iok /quiti
brzg has joined #zig
<g-w1>
oops, my ssh session got borked
<marler8997>
you back now?
<g-w1>
yes
<g-w1>
I understand it now
<g-w1>
i took a break and now get it
<g-w1>
so the ?type seems necessary
<marler8997>
yup
<marler8997>
we need to be able to build `build.zig` even when androidbuildlib is missing
<g-w1>
unless the error for @needsPackage is triggered on runtime instead of comptime
<marler8997>
g-w1, yes that coud work
<g-w1>
I would like that better since it is less open ended
<g-w1>
are there usecases in which that wouldn't work?
<marler8997>
I'm trying to think if it could even work like that
<g-w1>
if not, ill add it to the github issue
<marler8997>
so when androidbuildlib is missing, what type does @needsPackage return?
<g-w1>
a dummy type that allows anything to be called on it
<marler8997>
you would need some way to know whether it actually failed or not, so you can do if (needsPackageFailed) { // dont call anything from androidbuildlib or you'll get a compile error }
<marler8997>
g-w1, in that case, it's just as powerful as @tryImport
<marler8997>
just a little more convuluted, @tryImport with more steps
<g-w1>
ok yeah
<g-w1>
you seem to have put a lot of thought into this
<noam>
but...
<noam>
if androidEnabled is a comptime value - which it is, since build.zig - then that import will never happen
<marler8997>
noam, if it makes no sense then you're on the right track :)
<marler8997>
it shouldn't make sense when you first look at it and think about it
<noam>
Wait. that's a built-time dependency, right?
<marler8997>
androidbuildlib is a comptime import
<marler8997>
in build.zig
<noam>
build.zig needs it to build for android, right. Hm.
<g-w1>
to make people understand this better, I think you should put front and center that this allows stuff to compile with missing deps and that it is used at runtime
<noam>
I don't like this, at all. This means if you build with it not installed, you can't target android
<noam>
Even if you install it afterwards!
<noam>
You'd need runtime import resolution, which is horrendous
<marler8997>
nope
<noam>
You'd have to rebuild build.zig
<marler8997>
yup
<noam>
Which it won't know to do without trying to build anyways
<marler8997>
nope
<noam>
Personally, I think the better solution is to stop caching the result of building build.zig
<marler8997>
that's not a solution
<noam>
With stage2, building a build.zig file should be so blazing fast - even before incremental compilation - that invoking it as a script makes more sense IMO
<noam>
Then, you turn android_enabled into a comptime value.
<g-w1>
so build.zig is like config.h?
<noam>
`zig run`, basically.
<noam>
You rebuild it every time, and the cache catches it if the current config has already been built.
<marler8997>
interpreting build.zig instead of compiling it...that is an interesting idea, thinking...
<noam>
Make arguments available at comptime and voila.
<noam>
I don't think we should twist the language when we can just change how we run the file, instead.
<g-w1>
OMG, thats cool. a comptime script
<noam>
There's no reason to add concepts to the language that only need to exist for a single use case
<noam>
g-w1: exactly!
<marler8997>
so does this mean you wouldn't analyze the @import("androidbuildlib") if the user doesn't enable android with their command-line ?
<noam>
Yep
<marler8997>
yes that would also work
<noam>
Basically, it'd mean tweaking zig run - a *compiler concept* - so that arguments are available at comptime
<marler8997>
making all the configuration available at comptime is another solution
<noam>
I think this is better, because it adds options for a whole load of other use cases
<marler8997>
it does mean you'll have to re-compile build.zig every for every possible set of command-line options
<g-w1>
I like it better too, since it was already suggested!
<noam>
It means that you can use "dynamic zig" - the comptime language - for scripts!
<g-w1>
no, run it at comptime
<noam>
marler8997: no, only for the currently given one ;)
<noam>
in theory, if we do a finer-grained cache - as zyg will - it won't matter
<g-w1>
not yet, but why not just make pub fn build invoked at comptime by build_runner.zig?
<g-w1>
comptime { @import("build.zig").build(b) } then you just do what b says
<marler8997>
interesting, I'd have to think on this a bit but this could be a viable solution
<noam>
It is a thing, actually
<g-w1>
all you have to do is support comptime cli args
<noam>
Comptime zig is already fully dynamic
<noam>
Yep
<noam>
Comptime cli args seem like a much more elegant solution to me
<marler8997>
I need to know enough to make a PR
<g-w1>
pr? why not just another proposal? I can make if you dont want to
<marler8997>
it could be more elegant, but I need to understand it more
<marler8997>
so how would build.zig work if it executed at comptime?
<marler8997>
what would need to change?
<marler8997>
with build.zig specifically
<g-w1>
everything is declarative
<marler8997>
are you saying we can't implement any logic to select our build configuration?
<g-w1>
these 2 solutions are congruent, they both take cli args and do imports based on it. #2 works at comptime therefore not requiring a builtin, #1 runs at runtime therefore requiring a builtin. all that needs to change in the language is a way to pass args at comptime
<g-w1>
which I think would be good because the way build.zig does it anyways is not possible (I dont think) without using the build.zig api (ex. build-exe)
<marler8997>
andrewrk, if/when you see this, have you thought about making build.zig comptime only? Doing this would also be a solution to the build.zig bootsrap problem because it would get recompiled with every set of command-line arguments given to it.
<g-w1>
and it would be a solution to the securty problem
<g-w1>
3 birds with 1 stone!
<marler8997>
what 2 solutions?
<g-w1>
tryimport and comptime build.zig
<marler8997>
oh right, yes
<marler8997>
well, it wouldn't be tryImport anymore
<g-w1>
?
<marler8997>
it would be if (androidEnabled) { const al = @import("androidbuildlib"); }
<marler8997>
this would not compile because androidEnabled is comptime known
<marler8997>
*this would now compile
<g-w1>
the 2 solutions are either 1 or the other; you can ignore that
<marler8997>
ah, is that what congruent is supposed to mean?
<g-w1>
they do the same thing; ==
<marler8997>
they both solve the bootstrap problem
<marler8997>
but are both quite different
<marler8997>
@tryImport allows build.zig to make use of runtime
<marler8997>
so that's the crucial question, do we want build.zig to be able to use runtime or not
<g-w1>
for securty no
<marler8997>
I'm still fuzzy on the details for a comptime build.zig
<noam>
Hm. It's not really a security thing though
<g-w1>
why? now bulid scripts cant execute arbitrary commands
<marler8997>
yeah, comptime build.zig would be more sandboxed, though, I'm not intimately familair with all the restrictions on comptime
<noam>
Only if it runs fully at comptime, which isn't what I was saying and also isn't really possible.
<marler8997>
if it's viable, I do like the idea of comptime build.zig
<g-w1>
it *may* need an allocator although it might be able to be done with array ++ i think its possible though
<noam>
It fundamentally needs to be able to execute child processes.
<noam>
Well, hm
<marler8997>
noam, that's actually a good point
<marler8997>
you're right
<noam>
We could make a whitelist
<noam>
Disable inline asm, make sure it can't use syscalls, and give it a whitelist of functions to use at runtime
<noam>
but security is orthognal to this
<marler8997>
I'm still trying to figure out how comptime build.zig looks
<g-w1>
why childprocess? just add a Builder field called commands: [][]const u8
<marler8997>
so we don't have a build entry point anymore right?
<g-w1>
we have a build_runner that takes all the things declared in build.zig and actually executes it
<marler8997>
what are "all the things" exactly?
<g-w1>
exes, subprocess, packages, libs, c files, etc
<marler8997>
right, but how do I write this build.zig, what are these things? types?
<marler8997>
give me an example
<marler8997>
pub const MyApp = std.build.Exe("myapp", "myapp.zig"); ??? and then build_running uses reflection to get all the pub decls?
<marler8997>
*build_runner, not build_running
earnestly has quit [Ping timeout: 264 seconds]
<marler8997>
I think a path forward here might be to add support for a comptimebuild.zig, and prototype this idea
<g-w1>
const Builder = struct { exes: []Exe, } const Exe = struct { source_path: []const u8, packages: []Pkg } fn execute(b: Builder) { for (b.exes) |exe| exe.build() } fn build(e: Exe) { os.system("zig build-exe {}", .{e.source_path}); } marler8997 this is how I would do it. then pub fn build in comptimebuild would modify Builder
<marler8997>
mikdusan, looking
<noam>
g-w1: ahhhh, so you modify the builder, and only the builder is allowed to generate runtime code?
<g-w1>
exactly
<noam>
I likey.
<g-w1>
it is b = Builder{}; comptime { @import("build.zig").build(&b) } b.execute();
<noam>
Zig build would basically be a specialized zig run, which detects runtime code from the build script (NOT the root source file) and errors out if detected
<marler8997>
mikdusan, you're missing and if (b.option("enable-llvm")) around your block that uses @tryPackage("llvm"). The key here being that the block is surrounded by a runtime value
<marler8997>
*surrounded by an if that uses a runtime value
<mikdusan>
ah right.
<mikdusan>
well it's a comptime value to build.zig is it not?
<marler8997>
no, it's a runtime value
<marler8997>
-Denable-llvm is a an option passed to the compiled build.zig executable
<mikdusan>
ah yes. whups
<g-w1>
marler8997: does my explanation make sense? build.zig modifies a Builder at comptime and then build_runnner.zig runs it at runtime
<marler8997>
g-w1, I'm still groking your example
<marler8997>
now I'm the one who isn't understanding :)
<g-w1>
its exactly the same as it is now just comptime
<marler8997>
so build is now executed at comptime instead of runtime?
brzg has quit [Quit: leaving]
<marler8997>
I don't understand, what's "execute" and "build" functions for?
<g-w1>
/ build_runner.zig: comptime var b = Builder {}; comptime { @import("build.zig").build(&b); } b.execute(); // <- runtime
<marler8997>
I thought Builder was defined in build.zig?
<marler8997>
@import("build.zig").Builder?
<g-w1>
no, its still in std
<marler8997>
so then what was the code you pasted earlier? I thought it was the content of build.zig?
<g-w1>
thats the content of build_runner lol
<marler8997>
well that clears up one part of my confusion
<marler8997>
so what does build.zig look like?
<marler8997>
oh, it looks exactly the same as it does today?
<g-w1>
yes exactly
<marler8997>
Would that work?
<g-w1>
to do subcommands you just call b.subCommand and build_runner executes it after (maybe let the user vet it)
jicksaw has quit [Quit: ZNC is kill]
<g-w1>
Idk, i dont see why it would not
<marler8997>
we need to create a simple build_running.zig and see if it works
<marler8997>
I'm just not familair enough with comptime to know
<marler8997>
we can try the ziget build
<andrewrk>
oh baby is that a green CI I see?
<mikdusan>
marler8997: updated gist. take a peek when u have chance. afk for 10 mins.
<mikdusan>
confirmation bias!
<g-w1>
ok, its getting late for me, but I will put that on my TODO list and try tommorow. the only thing we need is comptime args now
<g-w1>
it should be possible though
jicksaw has joined #zig
<marler8997>
if you're off, then I'll be trying it before then :)
<marler8997>
mikdusan, taht won't compile when llvm is missing because llvm won't have the methods like getLibrariesToLink
<marler8997>
unless, is exec noreturn?
<g-w1>
beware, you might need to modify builder. I was thinking of just creating a builder type that resembles std.build just that works at comptime if the current one doesn't
<mikdusan>
marler8997: yes some kind of replace-existing-process
<marler8997>
ok, then the compiler shouldn't analyze the lines below if llvm is missing
<marler8997>
but it's not immediately clear, I would an if { .. } else { ... } to make it very clear
<mikdusan>
k
<g-w1>
OMG green ci
<marler8997>
flao, you can remove a level of nesting if you just put your (enable_llvm) around the block above it
<marler8997>
congrats on green CI, that's awesome!
<marler8997>
time to see if DOD is all it's cracked up to be
<g-w1>
marler8997: heck this can be even simpler. all we need to do is support comptime args to build.zig; thats it!
<g-w1>
thats super ez
<marler8997>
yeah I think you're right, though I'm not sure how different that is
<marler8997>
I suppose it's actually different because the logic now executes at runtime
<marler8997>
the big downside here is that we need to recompile build.zig with every combination of command-line arguments
<g-w1>
yes, but that should be fast; that is what noam was saying all along; weve gone full circle
<marler8997>
I don't think it's a big deal, but I'm not sure yet
<noam>
or full klein bottle. You can't prove we're only 2d!
<marler8997>
would the target name also be comptime?
<marler8997>
or with "zig build run ARGS", ARGS would be runtime correct?
<g-w1>
actually this can be implimented with the language right now. all we need is a build_build.zig which takes any args it has and passes them to build.zig at comptime
<marler8997>
need more context for that one
<g-w1>
build_build.zig gets executed at runtime with cli args. then it passes all its args to build.zig in a way that it can access them at comptime. this is a hack, but a good way to explore this
<g-w1>
and to show that it is possible
<marler8997>
so build_build.zig is the one that actually builds build.zig
<marler8997>
and how does it pass comptime args to it?
<mikdusan>
don't you still need a place to action code when pkg is not found? where does that go?
<g-w1>
the same way build.zig passes to main.zig
<g-w1>
mikdusan: presumably just an @compileError
<marler8997>
mikdusan, that's where your "exec" function is called
<marler8997>
g-w1, build.zig passes comptime parameters to main.zig?
<g-w1>
as build options
<mikdusan>
no I mean with build_build. is the point of build_build _only_ to avoid new builtin `@tryImport` ?
<marler8997>
mikdusan, pretty much yeah, but it's based off another proposal to make build.zig comptime only so it is sandboxed
<g-w1>
it is hypothetical. it would just be the compiler that collects the args and passes to build.zig at comptime
<noam>
and to test whether comptime CLI args are a good idea
<marler8997>
now we're exploring something in between the 2
<noam>
Yeah the compiler would have to do it
<noam>
not a build_build.zig file; it'd have to be part of `build.zig`
marijnfs2 has quit [Ping timeout: 264 seconds]
<noam>
Basically, invoke the comptime engine with the given args
<marler8997>
yeah we're talking about the details of a proof-of-concept
<mikdusan>
just build.zig --target wasm sandboxed :P
<marler8997>
the problem of missing imports goes away if all out build-configuration is provided at comptime, because now we can put our @imports inside if blocks that are known at comptime
<marler8997>
Unfortunately I don't know enough about comptime to really know whether limiting build.zig to comptime for it's configuration would even be viable, or a good idea, but seems like it could be
<marler8997>
so the best I can do is try to implement it and see what happens
<g-w1>
ill try to get build_build.zig working tmrw as a proof of concept too
<g-w1>
hmm theres no documentation on how to add a builtin comptime option as a build-exe flag? how do you do it
<andrewrk>
#7920 merged 🎉🎉
<g-w1>
yay 🎉🎉
<andrewrk>
big thank you to ifreund and vexu
<marler8997>
g-w1, yeah I'm not familiar with any concept like that
<g-w1>
build.zig must do it somehow with the -Doptions
<noam>
andrewrk: nice work! ☺
<marler8997>
those aren't comptime, their runtime
<g-w1>
they are comptime for main.zig, im thinking the same thing but for build.zig; its probably a hidden compiler flag
<noam>
g-w1: it generates a build_options.zig file
<g-w1>
ahhhhhhhhhhhhhhh, makes sense
<noam>
Which you import
<marler8997>
they don't get passed to main.zig
<noam>
You could have zig build generate a build_args package
<g-w1>
yep, will do a prototype like that
<marler8997>
noam, yeah generating something like that is what I hthought of
<noam>
Then you get args as a tuple-shaped structure in build_args
<marler8997>
so in `build.zig` @import("buildoptions")
<noam>
Yeah
<g-w1>
yep, then you can conditionaly import based on that
<marler8997>
I mean, I don't think we need a proof of concept for this
<marler8997>
I know it will work
<marler8997>
the question is whether this would be accepted
<marler8997>
and the bigger question is, whether build.zig could be executed entirely at comptime
<marler8997>
I'll be back in like 30
<g-w1>
imo its way more likeley than @tryImport for the buildoptions
<noam>
I agree - this is also based on something we *already support*
<noam>
We're just changing it a bit
<marler8997>
andrewrk, do you think making build options available at comptime for build.zig is likely to be accepted?
<marler8997>
be back
<g-w1>
the reason for this is to allow the same kind of conditional import that tryImport allows just in a more ziggy way
lukeholder has joined #zig
<andrewrk>
I'm expecting 90% of zig packages to not even have a build.zig
<andrewrk>
especially "leaf nodes" in the global dependency tree
<g-w1>
i tried to emulate the js version as much as possible
<marler8997>
there's no question that this feature is a corner case
<marler8997>
not only does not only apply to non-leaf nodes, it also only applies to nodes that have dynamic dependencies
<g-w1>
how do you test leafs without a build.zig?
<marler8997>
it sounds like your answer is, "I don't know I need to think about it" from your first impression, do you have an inkling about whether you would be more likely to accept @tryImport or comptime build options?
<g-w1>
i think the comptime build options would need to replace runtime ones for consistency but that is fine imo
<marler8997>
g-w1 huh?
<g-w1>
b.option and buildoptions.get(x) seem redundant
<marler8997>
we could make b.option return a comptime value, so we'd still be using the exact same API
<g-w1>
makes sense
<marler8997>
build.zig wouldn't actually import buildoptions, build_runner.zig would
<g-w1>
std.build right?
<marler8997>
oh right, yes
<marler8997>
ooo wait a second
<marler8997>
why don't we let build.zig say what options are comptime?
<g-w1>
so it doesn't have to rebuild every time? in that case why not just cache the combinations of options used?
<marler8997>
comptime options would need a special syntax in "zig build"
<marler8997>
right
<g-w1>
why special syntax? just do -Dthing the same way
<marler8997>
how would zig build know if it was a comptime or runtime option?
<g-w1>
oh, in your case where it specifies then idk, but if all r comptime it still allows caching of the args passed
<g-w1>
what is the benifit of runtime args in that case?
<marler8997>
means you don't need to rebuild build.zig
<g-w1>
see my above point about caching individual combinations of args
<marler8997>
sure, but we're talking about a corner case
<marler8997>
why should every project pay the cost of comptime args when only a few need it?
<marler8997>
you're going to recompile build.zig N exact duplicates of build.zig
<g-w1>
I guess
<marler8997>
we already need to distinguish between comptime and runtime options, it would be crazy to make "zig build run ARGS" comptime
<g-w1>
then just a b.comptime_option ig
<marler8997>
right
<marler8997>
but how to expose them on the command-line?
<g-w1>
the user doesn't have to know ;)
<marler8997>
zig build needs to know which options the user has given are comptime
<marler8997>
because that's how it knows it needs to rebuild build.zig
<g-w1>
can't it just look at b's comptime_options and see if it matches?
<g-w1>
or is that too much compiler+std integratino?
<marler8997>
b's comptime_options? what's b?
<marler8997>
oh, builder
<marler8997>
that' doesn't run until runtime
<g-w1>
yeah
<marler8997>
zig build does not even know the options until after it executes the "build" function from build.zig at runtime
<marler8997>
we could use a different prefix like "zig build -Efoo=bar"
<marler8997>
but, it doesn't seem like something that should be exposed to the end-user
<g-w1>
now if comptime_options is a comptime field, then the compiler could know what they are, not sure if that would work though
<marler8997>
it needs to know what options are comptime before it compiles build.zig
<marler8997>
we could possibly do something clever
<g-w1>
ah, i guess one solution is - stage2 is fast enough
<marler8997>
pre_build_runner.zig
<marler8997>
it imports build.zig but doesn't call "build"
<marler8997>
it relys on Zig being lazy, and it looks for a special symbol like "comptime_options" inside build.zig
<marler8997>
that's pretty clever if I do say so myself
<g-w1>
clever, but complicated
<marler8997>
it's convuluted and complicated
<marler8997>
it adds this extra compilation before build.zig is compiled
<marler8997>
but it should work
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<g-w1>
probably same amount of time to just cache every arg
<marler8997>
ok I think I have enough to create a PR with a proof-of-concept in Zig
<marler8997>
nah, caching every arg is completely different
<g-w1>
👍ok, ill be on the look out for pr
<marler8997>
that's 1 compilation per argument permutation
<marler8997>
this is 1 extra compilation, that's it end of story
<marler8997>
that can be cached
<g-w1>
yes, but stage2 is fast. with yours it has 1 compilation every time with pre_build_runner.zig right? so 2 if it changes vs 1 constant
<marler8997>
it's not just about speed, but storage as well
<marler8997>
not 1 compliation every time
<marler8997>
only 1 compilation ever
<marler8997>
you only need to recompile pre_build_runner.zig when build.zig changes
<g-w1>
ah, makes sense
<marler8997>
you don't need to rebuild it, even if the user provides different comptime options
sawzall has quit [Read error: Connection reset by peer]
<g-w1>
yep, this is pretty nice to poc and seems much more ziggy
kbd has joined #zig
sawzall has joined #zig
<marler8997>
it's a solution that works with the existing language, so that's definitely a plus
blackpawn has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<marler8997>
this means we don't use b.comptime_option
<g-w1>
at the very least if this didn't get accepted, you could probably emulate this somehow in userspace
<marler8997>
you can do this with a tool that runs before Zig's package/manager and "zig build"
<marler8997>
that's always an option, but is ugly, and will make my project not work as a dependency for other projects
<marler8997>
every project that uses my project will also need to run this "pre-package-manager-build-tool"
<marler8997>
and Zig's package manager probably won't have a way to hook into a dependency to run a pre-build step like this, so it actually probably isn't even a viable solution
blackpawn has joined #zig
<g-w1>
or just provide another fn build(b: *Builder, sslBackend: enum { ... }) that projs can hook into
<g-w1>
*comptime sslBackend: enum { ... }
<g-w1>
but i agree its not the best solution
<marler8997>
I'm not sure it's even a solution yet
<g-w1>
exactly :)
<andrewrk>
marler8997, yes my answer is, "I don't know, I need to think about it."
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<marler8997>
andrewrk, ok thanks, knowing where you stand saves me alot of time and effort, even knowing you're not sure
<andrewrk>
I didn't catch the conversation about comptime build options. to be clear, @imports are available to comptime code
<marler8997>
the current idea is to allow build.zig to specify some options as comptime
<marler8997>
this solves the @tryImport problem because now we can use those comptime_options to know whether or not we need certain imports
<andrewrk>
if you just put `pub const foo = 1234;` in a .zig file and @import() it, it will be comptime known
<andrewrk>
I think I'm missing something
<g-w1>
known to *build.zig* at comptime. this allows for build.zig to do contitional imports!
<marler8997>
if (comptimeOptionAndroidEnabled) { const androidbuild = @import("androidbuild"); ... }
<g-w1>
from the cli
<marler8997>
whears today we have if (b.option(bool, "androidEnabled")) { const androidbuild = @import("androidbuild"); ... }
<marler8997>
this will always fail because b.option is known at runtime, so the @import must always pass
<marler8997>
(this is why @tryImport can get around this)
<marler8997>
but allowing some options to be comptime is another solution, with no language changes required
ur5us has quit [Ping timeout: 246 seconds]
<marler8997>
g-w1, instead of pre_build_running.zig, we probably want something like extract_comptime_options.zig
<g-w1>
same idea right?
<marler8997>
yup
<andrewrk>
I see
<andrewrk>
I think the degenerate use cases that are driving these ideas are so far just slightly bigger than I can fit in my head at this time (with other stuff on my mind) and I'll need to dedicate some full, undivided attention to it
<marler8997>
sure thing, let me know if you want to discuss sometime as well, if you want to discuss soon I'll hold off on prototyping the comptime options idea and wait instead
<marler8997>
I know it will work so no proof-of-concept needed
<andrewrk>
will do
<g-w1>
note if we wanted to go full-comptime with build.zig for securty, this would be a byproduct of that and not be needed
<marler8997>
yeah true, I don't know if you've considered full comptime build.zig
<andrewrk>
I don't think comptime build.zig is feasible
<daurnimator>
marler8997: why like that?
<andrewrk>
we want to touch the filesystem and other stuff like that
<g-w1>
its for build.zig caching
<daurnimator>
marler8997: use the field name as the option name; and make the help come from a doc-comment?
<marler8997>
I was just copying the Builder.option function
<daurnimator>
andrewrk: I think build.zig should (comptime) create a dependency of commands to run; from a known set of available commands.
<daurnimator>
andrewrk: uh, DAG of commands to run
<g-w1>
andrewrk: that could be in a declarative api. we can mutate builder to touch all the stuff. b.exec(cmd) b.writeFile(name, string) then this would make a TODO in the runner to do that
<daurnimator>
for security reasons, I'd like to be able to run `zig build` without fully reviewing it first
<andrewrk>
it's an idea worth exploring
<daurnimator>
--> I want to be able to run `zig build` and trust it hasn't stolen some credentials on my machine
<mikdusan>
marler8997: what happens when @import("opensslbuild") fails because not found?
<daurnimator>
(or that it hasn't installed a rootkit)
<marler8997>
it's just a compile error
<daurnimator>
as it is: I have to run `zig build` in a sandbox that gets thrown away every time
<marler8997>
with this solution, I'm not sure how a package would know which packages need to be retrieved
<mikdusan>
marler8997: the solutions are thus not even remotely equal
<marler8997>
yea definitely not equal
<marler8997>
this one doesn't give build.zig any opportunity to try to handle a missing package
<daurnimator>
marler8997: that's good IMO
<daurnimator>
I would never want build.zig to download packages for me
<marler8997>
but it does allow build.zig to change what it needs to import based on the build configuration
<daurnimator>
infact I don't want build.zig to be even *able* to touch the network
<andrewrk>
I agree that build.zig logic should create a DAG only and the build runner should interpret this DAG and do the package downloading if necessary
<g-w1>
what is DAG?
<mikdusan>
giving comptime config to .zig is easy. in alternative solutions to @tryImport, if we dont have opportunity to codify not-found logic, then I don't know the point
<andrewrk>
Directed Acyclic Graph
<g-w1>
thx
<andrewrk>
never mind that though, I think that's not quite the right term
<andrewrk>
point is build.zig is declarative and the build runner takes that info and does the actual work
<daurnimator>
yep
<marler8997>
with the current package manager design, this would require the package manager to have some way to interact with build.zig to know which packages it is importing for any given comptime-configuration set
<daurnimator>
marler8997: my proposal to g-w1 the other week was that `pub fn build()` would be evaluated at comptime
<marler8997>
how does that tell the package manager which package it needs?
<daurnimator>
then *any* entry point could `const builder = @import("std.builder").build("build.zig"); for (builder.packages) |p| ......`
<marler8997>
just for clarification, this would mean the packages that build.zig uses would be in packages.json, but we wouldn't necessarily download them unless we determine that build.zig needs them
<marler8997>
groking...
<marler8997>
are you sure that's correct?
<marler8997>
I guess the point you're saying it, builder is the result of running build from build.zig
<daurnimator>
marler8997: if build.zig can be evaluated at comptime, then there's no reason you couldn't call it from any comptime code/context.
<marler8997>
but how does evaluating it at comptime help the package manager know what packages it needs?
<daurnimator>
and if the `build()` set up dependencies it wants in some field of the builder, then you would be able to interact with it
<g-w1>
imo a comptime build.zig would solve a bunch of problems and is worth a prototype
<marler8997>
I'm trying to picture how the package manager and "zig build" would be using build.zig at comptime
<marler8997>
like, when is the compiler running, how does the flow work here?
<marler8997>
today the flow is, compile build.zig, then run the exe to get inputs and outputs and run various build actions
<marler8997>
how does the zig build flow work if build.zig is invoked at comptime?
<marler8997>
Does it work the same way? you still compile a build exe and run it the same way?
<g-w1>
build_runner is still runtime
<marler8997>
ok, so then how does the package manager use build.zig?
<marler8997>
is it interacting with the resulting build exe, or is package-manager re-evaluating the comptime build function?
<marler8997>
if it interacts with the build exe function, I wonder if there's a way build_runner could output the packages it needs?
<marler8997>
build --zig-internal-list-packages
<marler8997>
wait no that doesn't work, because the @imports will fail
<mikdusan>
I think both altnernatives to tryImport discussed here need to show a use-case in enough detail to answer these questions and state what they do when an import is not found
<marler8997>
yeah definitely, I'm trying to work through a potential solution
<marler8997>
this means that the package manager MUST evaluate build.zig at compile time
<marler8997>
but then the imports will still fail
<marler8997>
yeah I don't think this works
<marler8997>
with @tryImport, what would happen is package-manger would compile build.zig, then it would run it to get the package list it needs
<marler8997>
in build.zig if (b.option(bool, "android")) { if (@tryImport("androidbuild")) |ab| { ... } else { b.needPackage("android"); } }
<mikdusan>
btw, s/tryImport/maybeImport/ to denote that it's an option? do we have any idiom fn naming for such things?
<mikdusan>
optional.
<marler8997>
that's fine with me
<marler8997>
I was also considering optionalImport
<marler8997>
try kinda means "error if this fails" so it doesn't really match
<marler8997>
but shoot, I don't think comptime build options solves this, that's freakin lame
<g-w1>
yeah, thats super lame
<mikdusan>
and counter-point (oops). `std.thread.Mutex.tryAcquire()` vs `Mutex.acquire()`
<marler8997>
so long as we agree this use case is valid, if we can solve this without @tryImport I'd love to hear ideas
sineer has joined #zig
<mikdusan>
ooh here's a thought. package_manager _is_ zig.exe, it does an embedded `zig.exe build` and a REGULAR `@import("androidbuild")` IPC's back to package_manager and says "need this...", pmgr does it's thing, and IPC back to compiler "here it is, continue onwards..."
<mikdusan>
oh right doesn't need to be IPC if embedded zig.exe . so callbacks or wahtever
<marler8997>
oh right, well that's what the --get-package-needs is
<marler8997>
poor mans IPC
<mikdusan>
if done that way, wouldn't need a new builtin
<daurnimator>
mikdusan: I really *don't* want us to support it in a callback sense
<marler8997>
how do we hook into the compiler to report missing imports, and not also cause other compile errors from the resulting type not being valid?
<marler8997>
and how do we know which imports we need? We only know this at runtime
<marler8997>
if (b.option(bool, "android")) { @import("android"); }
<daurnimator>
mikdusan: and by that I mean: I want *user interaction* with a new `zig` (or other) invocation to be required if there is any external resources being brough in
<mikdusan>
daurnimator: notwithstanding the runtime thing marler8997 just mentioned, none of what I said precludes user-interaction required if we setup package manager defaults that way
<marler8997>
"the runtime thing" is kinda the whole thing :)
<mikdusan>
heh i know
<mikdusan>
slow.. on the ... grok
<marler8997>
lol
<marler8997>
you did the same thing to me when I was talking about comptime build options so now we're even
<mikdusan>
dude you got a looooong memory dontcha ? :P
<marler8997>
lol, actually I think my memory is pretty shit
<marler8997>
I'm just laser focused at the moment
<marler8997>
everyone's input on this has actually been very helpful
<marler8997>
people have been bringing new and interesting ideas and we've really made some progress
<marler8997>
I have this theory that I have a horrible memory, and I constantly have to relearn/revaluate everything I know. It makes me very detail oriented and I get lost if I don't understand everything.
<marler8997>
normals don't seem to relate, maybe some fellow programmers feel the same way?
<daurnimator>
marler8997: IMO a build/package system needs the following 'phases': `download` -> `unpack` -> `build` -> `package`
<mikdusan>
so let's say pkgmgr is available as some kind of service, be it in another proc, same proc, whatever, run `zig build -Denable-androidstuff` and pkgmgr ready to intercept @import(),
<daurnimator>
where the `download` step *only* has downloaders for specific protocols (e.g. git, http, https), and no ability to run arbitrary code
<marler8997>
daurnimator, you could be right, I'm not sure, but my example allows for that flow
<daurnimator>
the `unpack` step (and all others) are *unable* to use the network
<daurnimator>
the `build` step is where most configuring happens
<daurnimator>
the `package` step should do nothing but `cp` from a temporary directory to the "installed" layout
<marler8997>
it might be confusing because zig's build.zig doesn't actually just do the build step
<daurnimator>
yeah
<daurnimator>
but for each of those steps, what you can do should be limited
<daurnimator>
e.g. in unpack step, no knowing the final locations
<daurnimator>
in package, the only thing you can see is output of build step; no network; no source files.
<marler8997>
daurnimator, like I said you could be right but I'd have to think about it
<marler8997>
with my example, compiling and querying build.zig could all be done in the download setp
<mikdusan>
daurnimator: some of today's processes are quite sophisticated for "building". and they necessarily include running a native binary.
<daurnimator>
mikdusan: I think we should explicitly *not* support such build systems.
<daurnimator>
for zig, we should say that any code that needs to run at build time must be comptime
sord937 has joined #zig
<mikdusan>
to what end? if security is a concern, I ask you to consider the plethora of autotool shenanigans that are executed every single time for many package builds. and no one goes through them with a security comb
<marler8997>
daurnimator, you're probably more familair with comptime restrictions, what benefit would be get by limiting build.zig to comptime?
<daurnimator>
mikdusan: that's exactly why
<marler8997>
give me an example of what we can't do at comptime
<marler8997>
like touch the filesystem (aside from imports)
<mikdusan>
and then we have qt which builds it's own compiler to compile some wacky interfaces
<daurnimator>
mikdusan: to run a autotools based build I have to spin up a whole VM; its time consuming and awkward.
<marler8997>
so you don't want build.zig to be able to read/process non-zig files to generate it's DAG?
<daurnimator>
marler8997: sure it can, `@embedFile` is a thing
<marler8997>
oh true
<marler8997>
so what can't we do then?
<mikdusan>
daurnimator: I think ruling out all builds that execute anything supplied by their sources would be huge
<mikdusan>
huge as in the number of things that would not be supported
<daurnimator>
marler8997: 1. can't reach the network. 2. can't read anything outside of build/src dir (e.g. my /etc/passwd file)
<marler8997>
can't run subprocesses?
<daurnimator>
marler8997: subprocesses should be from a predefined list (essentially only `zig build-*` commands)
<marler8997>
yeah I definitely think that's worth consideration
<daurnimator>
and then the `package` step able to create files in the passed destination directory/prefix
<marler8997>
it makes the DAG more pure
<daurnimator>
makes it parallelisable too
<marler8997>
which is good, except if someone has a valid use case that doesn't allow this, would have to think if there is one
kbd has joined #zig
<daurnimator>
I have a few in mind that I want to solve
<marler8997>
like?
<daurnimator>
e.g. for building a linux kernel module, I need to invoke the orc tool
<daurnimator>
(orc is an alternative to dwarf)
<marler8997>
but that doesn't require DAG modification right?
<marler8997>
you can still run subprocesses during the actual build
<daurnimator>
as I said above: I wanted a whitelist of subprocesses permitte
<marler8997>
how do you restrict runtime like that?
<daurnimator>
marler8997: what do you mean?
<marler8997>
you have a custom build step to call the orc tool, how to you prevent it from calling anything else?
<mikdusan>
I think these are policy decisions and build.zig/package_manager.zig features should make that policy an option or default, but shouldn't make it impossible to do more
<daurnimator>
marler8997: you create the DAG, and each DAG step has an action in it, e.g. "run zig build-obj" or "run zig build-lib"
<marler8997>
we're at runtime now, so anything is free to use the network/full filesystem/whatever
<daurnimator>
marler8997: so I haven't figured this out yet, but I imagine you can add to the white list, so e.g. `zig build --allow-build-subprocess orc=/path/to/orc`
<marler8997>
oh wait a second, does this pure Dag have no ability to add runtime code to it?
<daurnimator>
marler8997: correct.
<marler8997>
ah
<marler8997>
so at no point can you pass a function to the Builder that gets executed at runtime, interesting
<daurnimator>
yeah that's the idea
<mikdusan>
set daurnimator.lockdown=true
lukeholder has quit [Quit: Connection closed]
<marler8997>
It's an interesting idea. You're sort of forcing people to make their build logic more correct
<daurnimator>
we've got a blank-ish slate here... lets do it right
<marler8997>
I'm still unsure whether it would be too restrictive
<g-w1>
also it might be akward getting the output of cmds? how would you do it?
<marler8997>
for your orc idea, would this whitelist be a list in the zig standard library?
<daurnimator>
I think the most annoying thing would be that people have to write that whitelist every time: but that pain is intentional, its to force you to accept what the build system might run
<daurnimator>
g-w1: we already have files passing from one step to another in build.zig, see .addArtifactArg I think it is?
<g-w1>
getting the output of a cmd at comptime?
<daurnimator>
g-w1: you don't: you can get the output of a command during build and have it written to a file; then you can pass that file to another command
<daurnimator>
of course all commands would need to be on the whitelist
<marler8997>
is this whitelist in the standard lib, or in the project's build.zig file?
<g-w1>
ok, so like cmd("ls").pipe("file.txt") then read file.txt?
<daurnimator>
marler8997: project's build.zig
<daurnimator>
marler8997: or what do you mean?
<marler8997>
yeah that's what I meant
<daurnimator>
marler8997: the std libraries build.zig would have the default whitelist; then a build.zig would specify which (if any) additional commands it needs
<marler8997>
daurnimator you don't have an example of what such a build.zig would look like do you?
semarie has quit [Ping timeout: 240 seconds]
sineer has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator>
marler8997: uh, no different to what build.zig looks like today, except that build() would be called as `comptime build()`
<mikdusan>
how do you define what is allowed on the project whitelist?
<daurnimator>
mikdusan: I'm proposing that we would add it from the build special runner; and then check against it in RunStep
<mikdusan>
but there has to be something that says "ls" or "/usr/bin/ls" is allowed
<mikdusan>
are we supposed to add each thing to command line? I must not be seeing something here
<g-w1>
i think yes
<g-w1>
maybe it could be cached?
<mikdusan>
I have 10 different Xcode compilers on my system. and freely select between them.
semarie has joined #zig
<mikdusan>
each Xcode toolchain has many executables. It's not unheard of in complex projects do use different versions of compilers to overcome stupid compiler bugs building the same executable
<daurnimator>
mikdusan: in this scheme: yes you are. but... why would you be using `cc` and not zig's builtin supported `zig cc`
<mikdusan>
today, and for the foreseeable future, `zig cc` is not going to get the job done for UI and ios/tvos/watchos apps
<mikdusan>
It should be stated a closed build.zig would have the consequence of: "zig cc/c++" or bust.
<mikdusan>
I mean maybe that's ok. But let's just be CLEAR about it so when issues open up it's straight to "not supported".
<marler8997>
there can always be --ignore-whitelist
<mikdusan>
to be clear, that would mean it _IS_ supported
waleee-cl has quit [Quit: Connection closed for inactivity]
cjb has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
tnorth has joined #zig
<daurnimator>
mikdusan: do you need more than `cc`? in which case it might be `zig build --allow-build-subprocess cc=$(xcode some thing to get cc)`
neptunepink has quit [Ping timeout: 265 seconds]
wilsonk_ has joined #zig
neptunepink has joined #zig
wilsonk has quit [Ping timeout: 240 seconds]
<ifreund>
andrewrk: woot! \o/
<ifreund>
that diff on formatting src/ looks good
bitmapper has quit [Quit: Connection closed for inactivity]
<karchnu>
Hello guys, the french translation is almost here \o/ I'm reading it one more time, checking for spelling mistakes and maybe a few rewordings.
<g-w1>
fengb: ir.cpp:26806 and ir.cpp:26847 seems to get it. not sure why its not working
<fengb>
It works if I forward an existing @typeInfo, but not when I try to build it manually
<g-w1>
probably a subtle bug
<g-w1>
i have some time, so ill try to debug
<ikskuh>
karchnu: whooot? sweet!
<karchnu>
ikskuh: thanks! ^^
<karchnu>
Will try to push it in a few hours.
<ikskuh>
a lot of languages already :)
motiejus has left #zig ["User left"]
<marler8997>
ikskuh I'm not familiar with that proposal
<marler8997>
was that something you think might help with this problem?
<g-w1>
fengb: found the issue it checks the *ast* to see if it has a tag instead of the actual *type*
<g-w1>
lmao: if (decl_node->data.container_decl.auto_enum || decl_node->data.container_decl.init_arg_expr != nullptr) {
<g-w1>
it should check the type, not the ast note XD. ive seen this bug b4 in stage2
<fengb>
I wish I understood the compiler :/
<g-w1>
ir.cpp:14138 check that out
<g-w1>
the @Type works fine, its the switch thats the problem
<g-w1>
i feel like that is just some legacy code from when zig analyzed the ast
<g-w1>
andrewrk: should it even check the ast now that we have an ir? ^^
Akuli has joined #zig
<g-w1>
i feel like that pattern of checking the ast is used a lot in stage1
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<fengb>
I don't know what I'm looking at >_>
<fengb>
Worthwhile to add a test case though 🙃
<g-w1>
basically from my understanding, to see if a type had a tag, it checked the ast where it came from instead of the actual type which only works when you dont use @Type
dyeplexer has quit [Remote host closed the connection]
<ikskuh>
<marler8997> was that something you think might help with this problem?
<ikskuh>
yeah i think so. with this proposal you can scan for all *potential* imports
<marler8997>
what do you mean by scan?
<ikskuh>
"grep"
<marler8997>
and can these *potential* imports use build.zig's runtime logic to enable/disable them?
<ikskuh>
as yep
<marler8997>
i.e. can -Dandroid enable/disable an import?
<ikskuh>
and in case of build.zig we could make the "build runner builder" (what) scan for all imports and pass in as comptime known values which imports are available
<marler8997>
this doesn't seem possible, where's this proposal?
<ikskuh>
if(available_build_packages.bearssl) { } else { print("requires bearssl to be used!"); }
<marler8997>
thinking...
<ikskuh>
same as your proposal, but with existing language features :)
<marler8997>
loading...buffering...
<ikskuh>
andrewrk: can i convince you of @import(.std) ?
<g-w1>
function overloading?
<marler8997>
you might be onto something here
<marler8997>
so let me make sure I have this right
<marler8997>
before compiling build.zig, we scan it for all the imports it makes (we can limit it to package imports as that's the only ones I have a use case for)
<ikskuh>
g-w1: it's a builtin. they are magic anyways
<marler8997>
then we take those imports and create a module with comptime values for each import that indicates whether or not it has been included
<g-w1>
they behave like functions though with the definition. maybe @importStd(); would be better
<ikskuh>
g-w1: also @importRoot, @importSelf, @importPkg ?
<g-w1>
actually nvm, it can just take anytype :)
<marler8997>
this is actually functionally equivalent to @tryImport, it's just implemented through a dynamic module rather than supported in the general case
<marler8997>
I find this solution acceptable
<marler8997>
because it would work
<ikskuh>
g-w1: builtins take AST nodes though ;)
<ikskuh>
and it wouldn't make the the language more complex :)
<g-w1>
yeah, its fine
<marler8997>
we are making the build process quite a bit more compelx
<ikskuh>
i'm going to break every build file soon anyways :D
<marler8997>
although, I suppose my proposed solution isn't much better
<marler8997>
yeah, I'm totally fine with this solution as well
<marler8997>
if andrewrk, approves, then I'll be happy to make a PR for this
<ikskuh>
we first need the issue implemented though :D
<marler8997>
the "issue implemented"?
<g-w1>
its pretty easy to impliment import taking a string literal
<ikskuh>
#2206
<g-w1>
i can do it in stage2
<marler8997>
yeah that sounds easy
jokoon has joined #zig
<marler8997>
oh wait no, this mechanism still needs to print the needed packages back to the package manager
<marler8997>
so it's just extra steps to do @tryImport
<marler8997>
oh wait a second
<marler8997>
we don't need to scan build.zig
<ikskuh>
hm?
<marler8997>
all we do is provide a function that takes a comptime string with the package name and it only returns true for the packages is has
<marler8997>
So we don't even need #2206 to implement this!
<kbd>
I tried `var format = .{.{Color.green, "↑", Status.ahead}, ... }`, but I suppose that's not right, and `for (format) |f| {...}` to iterate over it, but that gives "error: unable to evaluate constant expression" on the for.
<g-w1>
use inline for
<g-w1>
because it is comptime
<kbd>
oh, that works.
<kbd>
Thanks!
<kbd>
oh, here's why that didn't work in the main code. What do I do about a `continue` in the loop, which gives "error: comptime control flow inside runtime block" on the continue?
<kbd>
I'll try to figure out how to write it differently.
<g-w1>
you may be able to do a regular for if you make it an array of structs instead of tuples because that is runtime i think
Xena is now known as Cadey
<kbd>
Is there any way to do destructuring in Zig, like what I did in the Nim? `for (color, token, code) in format:...`
<g-w1>
no
<g-w1>
the most you can do is add an enumeration with it `for (arr) |i, val| { }
<kbd>
looks like converting it to structs worked! I always try to avoid bothering y'all but I never would have known that I was running into a bug vs something I was doing wrong, or that structs vs tuples would make it runtime vs comptime. Thanks again for your help.
dongcarl has joined #zig
<andrewrk>
kbd, it's always ok to ask for help in here :) you just might not get an answer if people are distracted, or nobody knows the answer
Akuli has quit [Quit: Leaving]
<ed_t>
Is there a roadmap for zig someplace? not looking for date but rather milestones.