Simplify build.zig to use upstream webui C library building

[mochalins]

No description provided.

[jinzhongjia]

To be honest, I don't recommend doing this
I recommend deleting the initial upstream build.zig after zig is updated to 0.12, making it easier for zig-webui to directly reference the upstream source code.
But another upstream contributor re-added build.zig support to it, and I couldn't update to upstream in time when the zig master update broke build.zig (at least one other person's approval was needed)
It is a better solution to retain the build.zig of zig-webui, which will avoid excessive decoupling.
No need to maintain zig builds in two repositories
In my opinion, the upstream build.zig retains a bit extra
Unfortunately, the last discussion I chose to make concessions, so the upstream retains build.zig

more info: webui-dev/webui#383

[jinzhongjia]

This explains why there is still a build.zig in the upstream, and it looks like this build.zig is useless
So I don't intend to merge the PR

[AlbertShown]

So, you suggest removing build.zig from the upstream?
latest Zig now is 0.13.

[jinzhongjia]

Originally(When only I maintained build.zig) I only kept build.zig initially just to ensure compatibility with 0.11. Only after 0.12, zig can directly reference the source file of package.
So I suggest when 0.14 is released, we can just abandon 0.11 compatibility: webui-dev/webui#401 (comment)

At that point we can just remove build.zig

[jinzhongjia]

And it should not be far away from the release of 0.14

[AlbertShown]

Why not abandon Zig 0.11 now?
The latest version is already two new major version after 0.11.

[jinzhongjia]

This is because 0.12 and 0.13 were released only about two months apart, and they can be regarded as the same version.
The release of 0.13 was released by zig upstream to follow the llvm update (it actually only contains a small number of standard library changes)
So in fact, it is currently just a major version after 0.11

[AlbertShown]

Okay, I see 👍

[mochalins]

I don't necessarily agree with this, and below is my reasoning why:

1. The upstream C-only webui library should always have its own build.zig, so that C library users can optionally use Zig as only a build system. These users should not have to deal with the additional Zig bindings/wrapper. In fact, long term I believe that Zig as a de-facto cross-compiling build system for C will grow popular enough that it may replace several existing C build systems.
2. This Zig wrapper should exist not to provide the webui C library, but instead to provide a tailored Zig interface. As such, the build.zig for this wrapper should cleanly separate its concerns to focus only on providing the aforementioned Zig interface; in other words, just the Zig interface module and related tests/examples.

In fact, this separation of concerns in having a build.zig for both the C library and the Zig wrapper can also help Zig users. If a Zig user is already including other C libraries in their dependencies and wish to only use webui with marshaling other C library results (C-string pointers, C integers, etc.), it is more convenient for said user to directly use the webui library's C headers than it is to use a Zig interface. Having a separate build.zig for the C library will help in this case as well.

[jinzhongjia]

I agree with your statement, but what I don't agree with is that the upstream library cannot be updated immediately when the master changes and the build is damaged. In fact, I prefer to only maintain zig-webui.
And put build.zig in zig-webui. Users can also directly reference the c source file when referencing zig-webui.

[jinzhongjia]

Moreover, the current build.zig of the upstream library is not standardized, and it still uses some functions that have been deprecated since 0.12. That build.zig is not maintained by me, and we cannot guarantee the quality of the code used in the build.

[jinzhongjia]

Since I have other things to deal with in the past year, I cannot allocate extra energy to pay attention to the build.zig of the upstream library.
Of course, if you are willing to take over the maintenance of the upstream build.zig (to ensure the buildability of master), I have no problem
Just subscribe to ci's build errors. zig-webui will try to build master every day to ensure availability.

[mochalins]

I understand the concerns that patching upstream build.zig may be a slower process than updating zig-webui. However, on a technical standpoint this patching is necessary for webui anyway, and the upstream webui's build.zig should be cleaned up and updated to avoid deprecated functions regardless.

However, I believe these are concerns more about development process rather than concerns about the actual technical implementation. I think it would be worth a try to have this discussion with upstream webui maintainers to figure out a better process for updating the upstream build.zig.

[mochalins]

Sure, I'd be happy to help maintain the upstream build.zig, but I believe other Zig community members or C users of the Zig build process would also be willing to contribute. I think it could be a good idea to try more frequent maintenance of upstream build and see where things go from there.

[jinzhongjia]

Okay, I have no problem
My suggestion is that you can first take a look at the release notes of 0.12 and 0.13, and then initiate a PR on the upstream build.zig to fix some outdated methods.
There is a big difference in the build system between 0.11 and 0.12 and later.

[jinzhongjia]

@AlbertShown what do you think?

[jinzhongjia]

webui-dev/webui#501

[mochalins]

This is quite interesting, CI is failing with a dependency hash error only on 0.11.0. Looking deeper into this, I've realized that 0.11.0's package manager actually does not have a paths field in its build.zig.zon, so it is attempting to unpack and hash the entire dependency into cache without respecting the paths constraints.

As build.zig.zon can not case depending on Zig version, I think the only way forward is to delay this PR until Zig 0.11.0 support is dropped, or to stick to the previous build.zig of upstream webui.

[jinzhongjia]

The current approach recommends including the entire source code upstream

We can abandon 0.11 when 0.14 is released, and then reset the included path.

[AlbertShown]

@AlbertShown what do you think?

To be honest, I'm not sure.
Both solution work, we may use the easiest one to maintain, not necessary the perfect one.

[mochalins]

webui-dev/webui#525 will make this mergeable once updated to pull from latest upstream. I believe this should mean that zig-webui also drops support for Zig 0.11.0.

[mochalins]

Nota bene: I strongly suggest choosing to "ignore whitespace" in the GitHub diff viewer, in order to make this PR reviewable.

[jinzhongjia]

nice work