On 2025/03/19 16:55, Theo Buehler wrote: > It mostly looks good to me ports-wise, although I'm not at all convinced > by the devel/bear use case. It feels very expensive for what it provides. > I guess I'm just not the target audience. That's fine. > > Do we really want or need to ship these, especially the systemd one? > > lib/cmake/grpc/modules/ > lib/cmake/grpc/modules/Findc-ares.cmake > lib/cmake/grpc/modules/Findre2.cmake > lib/cmake/grpc/modules/Findsystemd.cmake
I wonder if they might reference each other, maybe I'll take a look if I remember to do so when it finished building ;) > I am really reluctant okaying this just because it is yet another Google > C++ monster that will significantly add to bulk build times. (especially on archs other than amd64/aarch64) > I can live > very well without this and its only prospective consumer. On the other > hand, nobody's really objected so far... Same for me. The other thing with Google C++ monster libraries as far as I've seen is that they often don't seem to concern themselves too much with cross-version compatibility, I think they may assume that the typical downstream user will vendor them. > What do others think? Yay or nay? > > All that said, if this goes in, I'm ok with importing devel/bear. > > > > > > > > > What's going on with plugins? I see grp_xxx_plugin binaries in PLIST, > > > but they don't look like anything I recognise as a plugin for any of > > > those languages..(and I wouldn't want plugins for those languages all in > > > a single port, e.g. their PHP stuff is https://pecl.php.net/package/gRPC > > > and built using normal pecl mechanisms, from a ports point of view it > > > will be a pain to handle all of these in one place due to interactions > > > between MODULES). Are those binaries actually useful for anything? > > > > > > > The same, copied from FreeBSD. I agree with you to disable all plugins. > > I have no current use-case for it. > > > > New tarball attached. > >
