Isuru Fernando

> one more aspect against the status quo is that even your described solution has a higher integration cost because the build scripts between static/shared would become more involved (or...

> I feel this is moving the goal posts; previously you asked what would break, now you ask why that feedstock needs a static lib. That's a deliberation per feedstock,...

> It currently [uses](https://github.com/conda-forge/onnxruntime-feedstock/blob/main/recipe/meta.yaml#L61) the static lib, but does that without being confused by shared-only CMake files, because those don't exist yet due to https://github.com/conda-forge/libprotobuf-feedstock/issues/68 (that issue needed upstream fixes...

> Yes, if we do it like you propose (no CMake targets for the static lib), I believe that would happen. You are not making sense to me at all....

> Currently, the CMake invocation in onnxruntime falls back on other means to detect libprotobuf-static (pkgconfig or whatever), but if we were to add native CMake files ($PREFIX/cmake/protobuf-*.cmake, see [equivalent](https://github.com/regro/libcfgraph/blob/master/artifacts/libprotobuf/conda-forge/win-64/libprotobuf-21.4-h7755175_0.json#L271-L276)...

> I don't know why this discussion needs to be so combative. I'm trying to solve (what I perceive to be) a genuine problem - we can disagree on how...

Yes, the same concern apply to Go packages. See also https://github.com/google/go-licenses I've no idea how others fix this.

@hadim, what @andfoy did for rust was to use a script to download licenses and put them in the recipe (and manually add licenses for packages that the script failed)....

For go, it's simple. See https://github.com/google/go-licenses#complying-with-license-terms

> Should this be extended to header only dependencies as well? Depends on the license. > For example, if you use pybind11, boost, etc, do you need to package the...