[PATCH weston 5/6] libweston: do not add libweston-$version to the Cflags

[Pekka Paalanen]

On Mon, 4 Jul 2016 16:02:23 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 4 July 2016 at 15:32, Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> From: Emil Velikov <emil.velikov at collabora.com>
> >>
> >> When managing headers there's normally two ways to handle them
> >> - with or without the subfolder.
> >>
> >> Opting for the latter case here, since it will provide direct feedback,
> >> whether one is using libweston-0 or any other version.
> >>
> >> Which in turn should deter (help prevent) issues like building/linking
> >> against multiple versions of libweston.
> >>
> >> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>  
> >
> >
> > I really prefer not to do that. It means supporting multiple versions of
> > libweston will lead to a really big #ifdef dance at the top of the file to
> > include every single version you might support, instead of a just a few
> > #ifdef around specific new/old functions you use.
> >  
> Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
> one wants to support multiple versions they will need a bunch of them
> either way.
> 
> Keeping things explicit will give (and/or save) you and others a fair
> bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
> you might say sad) example I've seen in the open-source Tizen world...
> or was it Android:
> 
> Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
> are introduced. Thus he/she adds both versions of libfoo in the
> configure pkg-config checks. At which point, you will have symbol
> collisions, seemingly random corruption and/or crashes.

Hi Emil,

I'm not sure I get that example.

I read the long IRC discussion between the two of you the other
day, and I have to say I'm on Quentin's side on this, solely because
switching from one libweston version to the next will cause lots of
"unnecessary" changes if you need to fix the #include directives
everywhere. I also do not think doing that mechanical excercise
will make anyone think about the actual ABI changes.

If we want to make sure users actually notice libweston ABI
changes, we need to make those as build-breaking API changes too.
That's the only feasible thing I can think of, unless we had someone
writing a checklist of all the ABI changes - a fat chance - and
hoping that downstream devs actually go through it.

Therefore a NAK from me too.


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