Build failure in dependency with Zig master

[mnemnion]

libvaxis can't build on the Zig master branch, due to dependency on libxev, tracked on #108 on that repo. The Zig master issue causing this is tracked at #20999.

[rockorager]

I haven't tried building libvaxis on zig master branch since 0.13 came out - is that the only build error you were seeing?

[mnemnion]

I missed this question, sorry. Yes, the build failure is in xev, and traces back to the user of @src(), that's being tracked by the mentioned issue. The build script doesn't move forward from there, so I can't tell if there would be knock-on effects, but the repo doesn't have @src() in it, so if there are other problems they don't come from that issue.

libxev has decided to track releases only, and not keep up with master, which is understandable. I'm keeping an eye on the @src() issue for my own library which needs it, and might be in a position to take a crack at adding a version-specific fix to libxev pending resolution of that question.

[rockorager]

Thanks for the context. I know there is extensive use of usingnamespace in libxev as well. I'm considering removing both that and aio from the main libvaxis repo and having them, essentially, as contrib files which can be dropped in to a project to use them as the event loop - or even just as examples of how to integrate with your own. This would drop the dependencies on them and keep libvaxis a bit smoother in upgrading versions.

That said - please let me know if this issue is blocking for you, and I will see about making a 0.14-dev branch of libvaxis that tracks zig master (probably needing to remove, or at least fork, many of the dependencies)

[mnemnion]

Not a blocker for me, thanks for asking.

As far as usingnamespace is concerned, the linked issue is still in the proposal stage, it hasn't been marked accepted yet. I would hope that libraries which are using it (this may not include libvaxis except transitively) will take the opportunity to comment showing how it's used in their codebase and asking for the feature to stay, I'm personally not in favor of removing it.

It does make sense to me for dependencies which aren't essential to the library to be optional in some sense, I haven't figured out how to make them not even fetch and build unless lazy compilation reaches them, but it might be possible (and should be if it isn't).

But please don't feel obliged on my behalf, I was just playing around with libvaxis, and keep a 0.13 binary on hand for just this sort of occasion.