https://bugzilla.redhat.com/show_bug.cgi?id=2334903 --- Comment #44 from Jan Drögehoff <sentrycraft123@xxxxxxxxx> --- (In reply to Benson Muite from comment #42) > (In reply to Anthony Oon from comment #38) > > It was discussed with the Ghostty maintainers that wuffs, highway, utfcpp, > > and cimgui are libs intended to be vendored sources that are configured with > > defines. Packaging would mean providing both header and source files which > > seems atypical. There is currently a vendored glad file for working with > > opengl. > > Most packaging uses shared libraries, and header files are provided. Would > be great if this can be supported in the Zig ecosystem. Vendoring should be > avoided if it can be. Zig does support linking to shared and static libaries (.so and .a) and is capable of parsing C headers But to give some more context about those specific libraries listed: - wuffs wuffs is written in their own custom language that can be transpiled to C, officially they only release a single .c file with no form of build infrastructure place the official recommendation is to just copy and paste it into your project - highway it should be possible to use the system highway shared libary instead of building it from source - utfcpp while utfcpp has an a build system (cmake to be specific) with everything configured to build a libary, its not supported and the developer is considering removing it in the future the only official instructions are "download, unzip, copy into your project" - cimgui cimgui (and by extension dear imgui) are expected to either be included as a submodule or directly vendored in the project, there is no instrastructure for compiling a shared libary and the fact that its common to create custom backends make it unsuitable for this. There are also existing packages that make use of imgui and bundle it like imhex or dolphin-emu. - glad2 the vendored glad stuff is only the generated output from https://gen.glad.sh its possible to regenerate it ourselves but I don't think there is any benefit with there being a likelyhood that a misconfiguration could break it. In general I don't think we should force projects to be compilable as a shared libary, especially if they say this is an unsupported path. > libxev webpage indicates it has very few dependencies: > https://github.com/mitchellh/libxev > Would be good to package separately. Happy to do this. libxev is a zig project and while its capable of generating a shared library any zig project wants to integrate directly with the zig code at this point in time the ecosystem and zig's package management is too immature to have dedicated zig packages. > Fedora prefers gcc unless for technical reasons it cannot be used. zig relies on clang for its C integration -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2334903 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202334903%23c44 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
