[PATCH 3/5] scanner: introduce --object-type option

[Pekka Paalanen]

On Fri, 26 Jan 2018 14:34:53 +0000
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 26 January 2018 at 02:44, Jonas Ådahl <jadahl at gmail.com> wrote:
> > On Thu, Jan 25, 2018 at 05:56:45PM +0000, Emil Velikov wrote:  
> >> On 25 January 2018 at 02:01, Jonas Ådahl <jadahl at gmail.com> wrote:  
> >> > On Wed, Jan 24, 2018 at 07:15:09PM +0000, Emil Velikov wrote:  
> >> >> On 24 January 2018 at 18:20, Derek Foreman <derekf at osg.samsung.com> wrote:  
> >> >> > On 2018-01-22 09:30 AM, Emil Velikov wrote:  

> >> >> >> Considering the status of the the name conflict series, should I
> >> >> >> re-spin this lot?
> >> >> >> I'm more than happy to tweak things - say rename the toggle, etc.  
> >> >> >
> >> >> >
> >> >> > I see there were two series proposed to control symbol visibility, yours and
> >> >> > Jonas'?
> >> >> >
> >> >> > Assuming that once we drop the symbol collision issue they both solve the
> >> >> > same problems, it would be good if we could focus on one going forward.
> >> >> >
> >> >> > Is this the chosen one?
> >> >> >  
> >> >> Right, the cover letter [1] covers some of the high-lights/differences.
> >> >> As a TL;DR: using static/shared is more common and gives us more
> >> >> flexibility for the future.
> >> >>
> >> >> So far Pekka is the only person who commented on the series/approach
> >> >> and seemed happy.
> >> >> I was expecting others to weight in - say Jonas ;-) I'll respin the
> >> >> series tomorrow.
> >> >>
> >> >> In hindsight --object-type={shared,static} is too much of a mouthful,
> >> >> I'll opt for --{static,shared} for v2.  
> >> >
> >> > I have no opinion of what variant to land (I'm slightly too lazy to
> >> > search for my own, and this is high up the inbox thanks to the replies,
> >> > so lets focus on this one).
> >> >
> >> > My only nit is using the term "object-type". I think refering to it as
> >> > "visibility" ("symbol visibility" if wanting to be extra verbose) where
> >> > one can say 'export', 'static' or 'private' is more accurate.
> >> >
> >> > "objects" are a Wayland protocol thing and that is not what we are
> >> > poking at here.
> >> >  
> >> Right using "object" might be misleading. On the other hand,
> >> --shared/--static are well known and dead-obvious.
> >> Plus it gives us flexibility to sweep more things under it, if we get
> >> some funky stuff in the future.
> >>
> >> Can I buy you on the different name?  
> >
> > --static is pretty clear, but --shared? Both WL_EXPORT and WL_PRIVATE
> > are "shared" but just different audiences.
> >  
> The actual symbol notation WL_EXPORT/WL_PRIVATE/other(?) is an
> implementation detail.
> That is "hidden" within the C files and never exposed outside.
> 
> There are two reasons for that:
>  - used internally, thus no point in polluting the namespace
>  - some compilers (older clang or was it the oracle/sun one?) are
> unhappy if the header is annotates, while the C file isn't

Hi,

looks like I too want to bikeshed about the option names.

I suppose "static" refers to static linking, not the static keyword in
C language? Took me a moment to realize that, but if everyone else
thinks it's obvious, fine.

I have pretty much the same comment on "shared" as Jonas. I suppose
it's more clear if you see that the options are either shared or
static. Would there be any downsides to using "export"? After thinking
it about a bit, "shared" is fine by me too.

In the end, I believe this is just a question of the help text for
these switches, is it clear enough.

Btw. Emil, would it hurt to have the generated code to #define
WL_PRIVATE only if it is not already defined? That would leave the door
open to user project hacks to define it to "static" if they really need
to be able to use conflicting protocols. Otherwise they'd run the
generated code once more through sed or awk.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180130/0c7aa1a4/attachment.sig>