On Wed, Jul 26, 2017 at 09:28:45AM +0100, Daniel Stone wrote: > Hi, > > On 25 July 2017 at 10:24, Pekka Paalanen <[email protected]> wrote: > > recapping the discussion from IRC, we pretty much agreed that prefixing > > is not a nice solution. Jonas found out that we cannot actually prefix > > everything, because there usually are references to other protocol > > things (like you would never want to prefix wl_surface). So it becomes > > very hard to prefix things appropriately. > > > > The alternative we discussed is solving a different problem: scanner > > makes all the public symbols in the generated .c files WL_EXPORT, which > > makes them leak into DSO ABI, which is bad. In my opinion, it should > > have never happened in the first place. But we missed it, and now it has > > spread, so we cannot just fix scanner to stop exporting, the decision > > must be with the consumers. So we need a scanner option to stop > > exporting. > > > > Quentin proposed we add a scanner option > > --visibility={static|compiler|export}. It would affect all the symbols > > exported from the generated .c files as follows: > > > > - static: the symbols will be static. > > - compiler: the symbols will get whatever the default visibility is > > with the compiler, i.e. not explicitly static and not exported > > - export: the symbols are exported (this the old behaviour, and will be > > the default) > > > > Obviously, the only way to actually make use of the 'static' option is > > for the consumer to #include the generated .c file. It's ugly, yes, but > > it solves the conflicting symbol names issue Jonas was looking into. > > > > In my opinion, the prefixing approach where we still cannot prefix > > everything in a way that one could use conflicting protocols in the > > same compilation unit, and where e.g. the static inline functions are > > not prefixed, is more ugly than the 'static' option. > > > > We are going to need an option to stop the exports anyway, and it seems > > like we can piggyback on that solution for the problem underlying the > > prefixing proposal as well. > > This sounds really good to me. > > Unfortunately, the release just went out last night without waiting > for any of these patches (or even pinging to see what their status > was?), so I guess we're not able to make xdg-shell stable for another > cycle. >:(
Well, we can still, just that anyone wanting to implement it in parallel to xdg-shell unstable v5 would have to wait. > > It's either that or just merge it post-beta anyway - which I wouldn't > actually mind to be honest. That's an option too. I don't have any objections really. Jonas > > Cheers, > Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
