Split spirv-tools into lib, cli and dev packages

[ZzEeKkAa]

Comment:

I guess it would be nice to split package the same way spirv-tools does it:
https://github.com/conda-forge/llvm-spirv-feedstock

Current list of files:

        "_path": "bin/spirv-as",
        "_path": "bin/spirv-cfg",
        "_path": "bin/spirv-dis",
        "_path": "bin/spirv-lesspipe.sh",
        "_path": "bin/spirv-link",
        "_path": "bin/spirv-lint",
        "_path": "bin/spirv-objdump",
        "_path": "bin/spirv-opt",
        "_path": "bin/spirv-reduce",
        "_path": "bin/spirv-val",
        "_path": "include/spirv-tools/instrument.hpp",
        "_path": "include/spirv-tools/libspirv.h",
        "_path": "include/spirv-tools/libspirv.hpp",
        "_path": "include/spirv-tools/linker.hpp",
        "_path": "include/spirv-tools/optimizer.hpp",
        "_path": "lib/cmake/SPIRV-Tools-diff/SPIRV-Tools-diffConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-diff/SPIRV-Tools-diffTargets-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-diff/SPIRV-Tools-diffTargets.cmake",
        "_path": "lib/cmake/SPIRV-Tools-link/SPIRV-Tools-linkConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-link/SPIRV-Tools-linkTargets-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-link/SPIRV-Tools-linkTargets.cmake",
        "_path": "lib/cmake/SPIRV-Tools-lint/SPIRV-Tools-lintConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-lint/SPIRV-Tools-lintTargets-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-lint/SPIRV-Tools-lintTargets.cmake",
        "_path": "lib/cmake/SPIRV-Tools-opt/SPIRV-Tools-optConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-opt/SPIRV-Tools-optTargets-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-opt/SPIRV-Tools-optTargets.cmake",
        "_path": "lib/cmake/SPIRV-Tools-reduce/SPIRV-Tools-reduceConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-reduce/SPIRV-Tools-reduceTarget-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-reduce/SPIRV-Tools-reduceTarget.cmake",
        "_path": "lib/cmake/SPIRV-Tools-tools/SPIRV-Tools-toolsConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools-tools/SPIRV-Tools-toolsTargets-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools-tools/SPIRV-Tools-toolsTargets.cmake",
        "_path": "lib/cmake/SPIRV-Tools/SPIRV-ToolsConfig.cmake",
        "_path": "lib/cmake/SPIRV-Tools/SPIRV-ToolsTarget-release.cmake",
        "_path": "lib/cmake/SPIRV-Tools/SPIRV-ToolsTarget.cmake",
        "_path": "lib/libSPIRV-Tools-diff.so",
        "_path": "lib/libSPIRV-Tools-link.so",
        "_path": "lib/libSPIRV-Tools-lint.so",
        "_path": "lib/libSPIRV-Tools-opt.so",
        "_path": "lib/libSPIRV-Tools-reduce.so",
        "_path": "lib/libSPIRV-Tools-shared.so",
        "_path": "lib/libSPIRV-Tools.so",
        "_path": "lib/pkgconfig/SPIRV-Tools-shared.pc",
        "_path": "lib/pkgconfig/SPIRV-Tools.pc",

@hmaarrfk what do you think?

[hmaarrfk]

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!

[ZzEeKkAa]

I've been thinking about two scenarious:

• for users that wants to use only binary, they do not need headers and cmake files;
• for projects that want to link to precompiled libraries they do not need headers, cmake files and binaries for the runtime. For example:
  • 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.

[hmaarrfk]

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!

[ZzEeKkAa]

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...

[hmaarrfk]

See discussion: conda-forge/conda-forge.github.io#1073

and maybe: conda-forge/cfep#48 <-- draft, but an idea.