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

[Emil Velikov]

On 7 July 2016 at 10:20, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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"
+1 for well use of quotation marks :-)

> 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.
>
"Anyone" is an overstatement. I might be a minority, but I would make
the effort of checking the API's (I use) in such cases. The whole
example and logic steers on the idea that the greater the effort
required by the user the larger likelihood that they will stop and
think for a second "wait there might be a reason behind all this
annoyance". As said, I'm likely a minority here.

> 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.
>
Yes, it's impossible to make thing completely bullet proof or even get
some (most?) users to read through the changelog. That is unless
things blow up in their face :-)

> Therefore a NAK from me too.
>
As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

Thanks
Emil