Open ZzEeKkAa opened 1 month ago
what advantages does it provide the end user of the spirv-tools package?
I would diminish the importance of "i want the most perfect package" for "i want a good user experience".
if the added work means extra delays in releasing a version, then it isn't very useful to split it.
If the added work means confusing in terms of what package to install, then it isn't very useful to split it.
I'm probably not aware of the issue of leaving it as a single package so do discuss!
I've been thinking about two scenarious:
llvm-spirv
links to libSPIRV-Tools.so
library, so pulling all binaries, headers and cmakes may be overhead;intel-graphics-compiler
may get use of it if it supports dynamic linking to spirv-tools.It's just enhancement for user experience, so they do not need to download unnecessary dependencies. I'm new to distributing applications and libraries, so want to hear feedback if that makes sense.
Generally speaking, "downloading fewer things" is not that useful. It becomes quite troublesome to understand which spirv-tools
package you have to add your to your recipe for each different case.
We could for example focus on understanding why the windows package is 12MB while the OSX and Linux ones are only 1MB. Typically this indicates that something is being statically linked on windows.
Generally speaking, the packaging burden only "grows" with time (since you want to build more interactions between software). Your time is the most precious resource here. So if the 1MB download is troubling for your workflow, by all means, make the PR, but maybe its ok and you can spend your time focusing on using your package ;)
PS. I am trying to reduce the download size and compilation complexity of qt6-main, so its not that I disagree with you, just the graphics stack is complicated enough, so I don't want to put undue burden onto you for marginal gains!
Thank you @hmaarrfk ! That's great advice. I may be obsessed with creating ideal package, so your comments totally makes sense. I guess it is good idea to invest time to solve the problem only when it is really the problem.
BTW, do you know if there is a standardize guideline how to split packages into release
, library
and development
parts? It fills like a common task (llvm
, llvm-spirv
, level-zero
, etc..) I see some have approach lib<pkgname>
for dev, lib<pkgname><major>
for library and <pkgname>
for release, while others have <pkgname>
and <pkgname>-devel
. By not having standard way to approach naming it indeed causes confusion what package to use in your recipe...
See discussion: https://github.com/conda-forge/conda-forge.github.io/issues/1073
and maybe: https://github.com/conda-forge/cfep/pull/48 <-- draft, but an idea.
Comment:
I guess it would be nice to split package the same way
spirv-tools
does it: https://github.com/conda-forge/llvm-spirv-feedstockCurrent list of files:
@hmaarrfk what do you think?