Changing the default could break lots of stuff downstream, would you mind switching the default to False to match the current behavior?

First: I can change the default, if that's what's needed.

Points:

• Most other packages I am currently aware of have a default of shared library instead of static library. So I'd prefer that. Even though it might be a small breaking change.
• Could you elaborate on a use case that might break?
  • Most (all?) build systems should gracefully handle shared libraries instead of static ones.
  • If people want to build a static executable, they most likely have a global ~shared setting, because of all the other libraries.
  • The possibly remaining use cases should be quite minor and special. Those users most likely "know, what they're doing".

Most other packages I am currently aware of have a default of shared library instead of static library.

Yes, that could be definitely the case for Spack packages but the default for this one has always been static. I would be totally cool with shared objs but the point is that switching defaults is a matter of Spack policies I guess, and I'm not a maintainer so I think we should ping @adamjstewart

Could you elaborate on a use case that might break?

Everyone that passes archives to the linker, for example. That's how CIs break and people end up blaming package managers.

• IMHO build systems that pass the archive directly to the linker instead of -L{path} -lgrpc are broken and should be fixed. (Fixed by either fixing the build system or explicitly doing depends_on('grpc~shared') in spack.)
• Yes, let's wait for adamjstewart's comment.

Repetita iuvant:

That's how CIs break and people end up blaming package managers.

That said my policy is that the maintainer of a package has the last word on semantic changes, so if it is fine with @nazavode it's green light also for me.

That said my policy is that the maintainer of a package has the last word on semantic changes, so if it is fine with @nazavode it's green light also for me.

Considering grpc just in the context of Spack (like for the point raised by @adamjstewart) this PR is fine as no packages depends on it and the change doesn't affect the functionalities provided by grpc, both the compiler plugin and the libraries. On the other hand, considering grpc used in the wild and deployed via Spack, this change would break everyone relying on the presence of archives, so I would prefer to avoid it if not necessary since I tend to see Spack as a tool suitable for production use. In summary: for the package maintainer is a no, for Spack as a whole is fine, looks like a deadlock :)

edit: jokes aside, I'm cool with either policy Spack is willing to enforce, consistency across the whole project is a value I would be happy to pursue.

Can we build both shared and static libraries? I think that's the default for most packages.

Can we build both shared and static libraries? I think that's the default for most packages.

Never tried myself but I think it's doable as long as the compiler plugin knows which one to pick. @ChristianTackeGSI would you mind giving it a try?

cmake isn't great at building both at the same time, really. At least AFAIK. (Not a cmake expert).

If this makes things easier for everyone, I am happy to just continue building static libraries as before and thus only giving people who need it, the option to build shared libraries?