Closed jinzhongjia closed 1 month ago
Imho this is not the right way if would could easily update in a more inclusive way that extends capabilities. I'm opening an example PR to have something concrete. Let me know if that works for you @jinzhongjia
It could enable to build zig-webui
without the need to make the adaptions and also extend the capabilities over here.
You don’t understand what I mean. Starting from 0.12, zig-webui no longer depends on webui (but zig will still build webui’s build.zig). My requirement is that webui’s build.zig will no longer fail to build in 0.13. , even if it returns directly, there is no problem
And I don’t know if you have checked the change log of zig and the changes of zig master. The current build.zig of webui is not good for 0.13 or even 0.12 because it uses a lot of deprecated APIs.
Of course, there is no problem with the PR you mentioned. It does meet my requirements and ensures that zig-webui can be compiled and passed.
I 100% understand what you mean. It's just that if there are several way of fixing things I care about fixing things in a good way.
The changes I submitted are not just checked locally, they are also tested in an automated CI run on all platforms.
However, the consequence is that when the master changes, webui will fail to build again. If 0.13 is detected and returned directly, it can avoid the trouble of maintaining webui's build.zig.
I want to apologize in advance for the harsh words I'm going to say, "I don't know that the better solution you are referring to is just to ensure that all compilations pass"? Zig has currently not command Lazypath (0.12), and even directly marked it as deprecated in the master
If there are more breaking changes at zig-dev, let's pin the working zig-version to return early.
Also, if there are some you will notice at zig-webui, and if the fix is simple you can also submit it here, this should just add some seconds of additional work. Else we can always pin it
https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L79 https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L83 https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L91 https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L95 https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L123 https://github.com/webui-dev/webui/blob/373c5467026582bdee2c1fddd9f0b620b168884b/build.zig#L140
According to the release log of zig 0.12, it can be said that these are incorrect usages.
But the problem is that if there is a fixed version, what about nightly users? Most users of zig use nightly, even me
This is also the reason why I separated the build.zig files of different versions on the webui before, because putting them in one build.zig file and ensuring compatibility made the code very unreadable.
I think you don't understand :D. Please read.
The path changes you are mentioning and the zig versions support is extended and tested in the linked PR above.
Now what I say is that if another breaking change at zig-dev should happen that breaks building, we can still do you approach of pinning the zig-version at webui C to a working version and return early. So you can handle it in whatever way in in whatever quality you want at zig-webui. Until then, when it works with the linked PR as suggested, it is imho the better solution.
Now I have no more time for discussion, so no more responses from my side.
Also sorry from my side, you can test, if it is fixed for you, else let's update accordingly.
ok,you are right
I get it
I just saw the conversation, I'm not a Zig developer, so whatever you decide. @jinzhongjia @ttytm
Close this PR,and merge the other
There are no major changes, just adjusting the logic so that nightly can pass