Closed jinzhongjia closed 2 months ago
OK, I have test, I think all things are ok! Can you approve this PR? @neroist
Wheres the issue with using one build file? To me it looks similar to the zig-webui workfows lots of redundancies. Imho it could be simpler to read and maintain when putting some effort into more intelligent code design and structure
Wheres the issue with using one build file? To me it looks similar to the zig-webui workfows lots of redundancies. Imho it could be simpler to read and maintain when putting some effort into more intelligent code design and structure
I separated the build files to ensure compatibility and maintainability, because zig's build system api has changed a bit in the last two versions, making it easy to break the availability of the other versions when updating the logic if we put all the code in one file once nightly changes
As for the zig-webui workflows, I copied the webui exactly
Of course, my current design does have redundancy, so maybe I should just say that they are divided into two files
The benefit of the current scheme is that I only need to update 0.13. Now 0.13 is same as 0.12, but I'm not sure whether zig's build system api will change After all, it hasn't released 1.0 yet
Wheres the issue with using one build file? To me it looks similar to the zig-webui workfows lots of redundancies. Imho it could be simpler to read and maintain when putting some effort into more intelligent code design and structure
Very good, I have now found a way to solve the above problem. We only need to keep a build.zig later to ensure 0.11
compatibility.
zig adds the ability to use C packages non-invasively in 0.12
No changes for code logic, just adapt to zig
nightly
Now, zig
0.12
has been released, zignightly
is0.13
And I need some test for this PR!