[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Review Request 110962: Switch to an external LibRaw
From:       Rolf Eike Beer <kde () opensource ! sf-tec ! de>
Date:       2013-06-12 6:37:44
Message-ID: 4094223.6YuHngs6dC () donald ! sf-tec ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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
["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]