Review Request 110962: Switch to an external LibRaw

[Rolf Eike Beer]

Vadim Zhukov wrote:
> > On June 12, 2013, 7:46 a.m., Vadim Zhukov wrote:
> > On June 12, 2013, 7:46 a.m., Vadim Zhukov wrote:
> > > cmake/modules/FindLibRaw.cmake, line 43
> > > <http://git.reviewboard.kde.org/r/110962/diff/2/?file=149642#file149642l
> > > ine43>> > 
> > >     So what if upstream changes:
> > >     
> > >     #define LIBRAW_MAJOR_VERSION 1
> > >     
> > >     to:
> > >     
> > >     enum     LIBRAW_MAJOR_VERSION     1   // my major version
> > >     
> > >     ? Or what if those definitions go to another header file, like
> > >     libraw_version_1.h, and libraw_version.h becomes a stub?
> I mean:
> 
> enum    {
>   LIBRAW_MAJOR_VERSION     1   // my major version
> };
> 
> of course.

Then we would need to change the Find module. That is the same as when they 
decide to rename the library to libraw1.so or something. But maybe until then 
someone has improved their released sources to also install a 
LibRawConfig.cmake.

Yes, you are right, this is not absolutely future proof. Like it is in 
basically every Find*.cmake module out there in the world and will always be. 
This can't be fixed in a Find*.cmake module, that is why we (CMake devs) 
propose to ship a *Config.cmake with the software instead whereever possible. 
Can we now please stop this debate, this will not lead us anywhere because it 
can't be fixed.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130612/7b99e48e/attachment.sig>