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

[Daniel Stone]

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. >:(

It's either that or just merge it post-beta anyway - which I wouldn't
actually mind to be honest.

Cheers,
Daniel