[PATCH wayland 2/3] scanner: Allow adding a prefix to exported symbols

[Jonas Ådahl]

On Wed, Jul 26, 2017 at 09:28:45AM +0100, Daniel Stone wrote:
> Hi,
> 
> On 25 July 2017 at 10:24, Pekka Paalanen <ppaalanen at gmail.com> 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