Re: [Openexr-devel] FindIlmbase.cmake & FindOpenEXR.cmake

[Ashley Whetter]

> A downstream project still has to maintain their FindOpenEXR.cmake modules 
> until they are 100% sure that they will never encounter a version <= 2.2, 
> right?
Yep that's right. Or they can choose to only use configs anyway.

There are many upstream projects that have opted to provide config packages but 
no Find module, mostly because it's easier to maintain that way.

> By any chance, is the package info preferentially used over the 
> FindBlah.cmake if both are present?
It depends how find_package is called. If find_package is called with the 
signature from the first code snippet here 
(https://cmake.org/cmake/help/v3.0/command/find_package.html) then it will look 
for a Find module before a config package. Otherwise it will prefer a config 
package.

On Mon, 15 Feb 2016 13:11:53 -0800, Larry Gritz <address@hidden> wrote:

> Thanks, that's exactly what I needed!
> 
> Now, what happens when there's a mixed ecosystem of old OpenEXR installations 
> (i.e., current and past ones) for which people are using Find modules, and 
> new ones (after your patch is accepted and a 2.3 version is eventually 
> released)? A downstream project still has to maintain their FindOpenEXR.cmake 
> modules until they are 100% sure that they will never encounter a version <= 
> 2.2, right? By any chance, is the package info preferentially used over the 
> FindBlah.cmake if both are present?
> 
> 
> 
> > On Feb 15, 2016, at 12:34 PM, Ashley Whetter <address@hidden> wrote:
> > 
> > I'll answer your questions in a different order than you asked them because 
> > it might make a bit more sense that way around.
> > 
> >> Is there an ELI5 for why package is preferred to the exclusion of a 
> >> FindOpenEXR.cmake module?
> > The ELI5 answer is that a config-file package provides dependency 
> > information. So a Find module usually just says "here's every library and 
> > include directory for that", whereas a config-file package says "here's 
> > each library in this package, and here's what each depends on and what 
> > include directory each needs". To user this means that instead of linking 
> > against everything in OpenEXR for example, they can link against only the 
> > libraries that they need to. There's also magic that cmake can do under the 
> > hood about what the imported library needs but I won't go into that.
> > 
> > The dependency information provided by a config file also includes external 
> > dependencies, so an user package wouldn't need to know that OpenEXR needs 
> > zlib for example, because the config file takes care of it.
> > 
> > Another big advantage is that the package can provide much more specific 
> > information about the project and/or how the project was built. For example 
> > we can specify the version of the project exactly in the config-file 
> > package, whereas a Find module might have to regex search header files for 
> > that information or might not have that information available at all.
> > 
> >> Is that the preferred method now for anything using CMake?
> > Yes. Anything that is "cmake aware" (ie is built with cmake) and that can 
> > be consumed by external projects as a dependency should provide a package.
> > 
> > As well as the above reasons, a motivation for this is that if every 
> > project supplied a Find module to go in the cmake Modules repository then 
> > there would be an impractical number of Modules in there. As you suggested, 
> > projects could supply their own Find modules in their own repositories for 
> > users to use, but what if that module gets updated? The user would have to 
> > know to update their copy of the Find module, and if not than it might not 
> > be compatible with new versions of the project.
> > 
> >> Is that expected to work on all systems? All platforms?
> > Yes and yes!
> > 
> >> If there are multiple OpenEXR releases installed?
> > Yes! A config-file package provides the information specific to that build 
> > of the project. So I could have OpenEXR installed as a system library and 
> > also installed somewhere in my home directory, and I can tell cmake to use 
> > either installation of OpenEXR when building my library. In fact the way 
> > we've exported the package in the pull request config-files mean that you 
> > don't even need to install OpenEXR! You could point cmake to the build 
> > directory of OpenEXR instead.
> > 
> > As user can specify an installation to use by either appending the 
> > directory to CMAKE_PREFIX_PATH or by specifying the location of the package 
> > specifically with <package>_DIR. See 
> > https://cmake.org/cmake/help/v3.0/command/find_package.html#command:find_package
> >  for more info on this (about half way down the page).
> > 
> > 
> > I encourage you to read the documentation on packages if you want to know 
> > more: https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
> > 
> > Sorry, I know that was quite big for an ELI5 answer but I hope it helps you 
> > understand it!
> > 
> > Ashley
> > 
> > On Mon, 15 Feb 2016 10:28:25 -0800, Larry Gritz <address@hidden> wrote:
> > 
> >> Maybe I'm just inexperienced with the package stuff. Is that expected to 
> >> work on all systems? All platforms? If there are multiple OpenEXR releases 
> >> installed? Is there an ELI5 for why package is preferred to the exclusion 
> >> of a FindOpenEXR.cmake module? Is that the preferred method now for 
> >> anything using CMake?
> >> 
> >> 
> >> 
> >> 
> >>> On Feb 15, 2016, at 5:26 AM, Ashley Whetter <address@hidden> wrote:
> >>> 
> >>> If there aren't any comments on this then could it be merged?
> >>> 
> >>> Ashley
> >>> From: Ashley Whetter <mailto:address@hidden>
> >>> Sent: ‎08/‎02/‎2016 14:05
> >>> To: Larry Gritz <mailto:address@hidden>
> >>> Cc: address@hidden address@hidden <mailto:address@hidden>
> >>> Subject: Re: [Openexr-devel] FindIlmbase.cmake & FindOpenEXR.cmake
> >>> 
> >>> I just wanted to make the mailing list aware of this pull request 
> >>> (https://github.com/openexr/openexr/pull/178). As the pull request 
> >>> description says, OpenEXR is now found by other libraries by exporting 
> >>> itself as a package, instead of the consumer library using Find modules.
> >>> 
> >>> It may still be worth having a discussion about whether or not it's worth 
> >>> creating Find modules. For example they'll have the advantage of being 
> >>> able to find older versions of OpenEXR that don't export themselves.
> >>> There's also the consideration that it means that it's more work for us 
> >>> to create and maintain the modules.
> >>> 
> >>> If it is decided that Find modules should be created as well then they 
> >>> should be made to be target based (so that it's somewhat interchangable 
> >>> with the package export), and not the old style of Find module that I did 
> >>> in the original pull request 
> >>> (https://github.com/openexr/openexr/pull/167). I also think that they 
> >>> would need to be submitted to (and also possibly maintained in) the cmake 
> >>> repository rather than on the openexr repository.
> >>> 
> >>> If sticking with only package exports then I think that the version 
> >>> number should be bumped so that Linux distros that supply openexr via 
> >>> their package manager are likely to pick up the new version with package 
> >>> exports, and increasing the chance of users having the openexr cmake 
> >>> package installed in their system libraries.
> >>> 
> >>> Ashley
> >>> From: Larry Gritz <mailto:address@hidden>
> >>> Sent: ‎23/‎01/‎2016 17:26
> >>> To: Ashley Whetter <mailto:address@hidden>
> >>> Cc: Piotr Stanczyk <mailto:address@hidden>; address@hidden address@hidden 
> >>> <mailto:address@hidden>
> >>> Subject: Re: [Openexr-devel] FindIlmbase.cmake & FindOpenEXR.cmake
> >>> 
> >>> That would be great!
> >>> 
> >>> Here are a few I found from "reputable" sources that presumably have seen 
> >>> a lot of use. It would be good to look them over and synthesize the best 
> >>> ideas into a canonical one that is as simple and robust as possible so 
> >>> nobody is tempted to modify it downstream.
> >>> 
> >>> Intel: 
> >>> https://github.com/embree/embree/blob/master/common/cmake/FindOpenEXR.cmake
> >>>  
> >>> <https://github.com/embree/embree/blob/master/common/cmake/FindOpenEXR.cmake>
> >>> 
> >>> NVIDIA texture tools: 
> >>> https://code.google.com/p/nvidia-texture-tools/source/browse/trunk/cmake/FindOpenEXR.cmake
> >>>  
> >>> <https://code.google.com/p/nvidia-texture-tools/source/browse/trunk/cmake/FindOpenEXR.cmake>
> >>> 
> >>> Blender: 
> >>> https://github.com/dfelinto/blender/blob/master/build_files/cmake/Modules/FindOpenEXR.cmake
> >>>  
> >>> <https://github.com/dfelinto/blender/blob/master/build_files/cmake/Modules/FindOpenEXR.cmake>
> >>> 
> >>> OpenSceneGraph: 
> >>> https://github.com/dfelinto/blender/blob/master/build_files/cmake/Modules/FindOpenEXR.cmake
> >>>  
> >>> <https://github.com/dfelinto/blender/blob/master/build_files/cmake/Modules/FindOpenEXR.cmake>
> >>> 
> >>> 
> >>> 
> >>>> On Jan 23, 2016, at 12:37 AM, Ashley Whetter <address@hidden 
> >>>> <mailto:address@hidden>> wrote:
> >>>> 
> >>>> I've already implemented a FindIlmBase and FindOpenExr in this pull 
> >>>> request: https://github.com/openexr/openexr/pull/167 
> >>>> <https://github.com/openexr/openexr/pull/167>
> >>>> Because ilmbase and openexr are built with cmake though, it's supposed 
> >>>> to export itself as a package that can be used by find_package instead. 
> >>>> I started an implementation of this earlier this week to replace the 
> >>>> Find files in that pull request but not had time to finish it yet.
> >>>> As you're asking about it I'll make this a priority and try and get it 
> >>>> finished asap. Because you're right, it's difficult to know what's best 
> >>>> with no standard version.
> >>>> 
> >>>> Ashley
> >>>> From: Piotr Stanczyk <mailto:address@hidden>
> >>>> Sent: ‎23/‎01/‎2016 07:19
> >>>> To: Larry Gritz <mailto:address@hidden>
> >>>> Cc: address@hidden address@hidden <mailto:address@hidden>
> >>>> Subject: Re: [Openexr-devel] FindIlmbase.cmake & FindOpenEXR.cmake
> >>>> 
> >>>> I see your point ... google seems to come back with quite a few, alas.  
> >>>> I can see from the OIIO thread its not as easy as could be. 
> >>>> 
> >>>> I've logged an issue here : 
> >>>> https://github.com/openexr/openexr/issues/176 
> >>>> <https://github.com/openexr/openexr/issues/176>
> >>>> 
> >>>> Thanks
> >>>> 
> >>>> -Piotr
> >>>> 
> >>>> 
> >>>> On 22 January 2016 at 23:10, Larry Gritz <address@hidden 
> >>>> <mailto:address@hidden>> wrote:
> >>>> These don't seem to be a standard bit of cmake yet, and so countless 
> >>>> divergent approaches to them can be found across a wide number of 
> >>>> projects. Just google "FindIlmbase.cmake".
> >>>> 
> >>>> Is there any consensus on the best one? (It sure as heck isn't mine, 
> >>>> which I think is the single ugliest one that I've found yet, I'm 
> >>>> embarrassed to say, and I'd like to replace it and pretend my current 
> >>>> one never existed.)
> >>>> 
> >>>> It would be great if a particularly good one was incorporated into the 
> >>>> ilmbase/openexr distribution itself as the canonical one that everybody 
> >>>> could use.
> >>>> 
> >>>> --
> >>>> Larry Gritz
> >>>> address@hidden <mailto:address@hidden>
> >>>> 
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> Openexr-devel mailing list
> >>>> address@hidden <mailto:address@hidden>
> >>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel 
> >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
> >>>> 
> >>> 
> >>> --
> >>> Larry Gritz
> >>> address@hidden <mailto:address@hidden>
> >>> 
> >>> 
> >> 
> >> --
> >> Larry Gritz
> >> address@hidden
> >> _______________________________________________
> >> Openexr-devel mailing list
> >> address@hidden
> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> > 
> > 
> 
> --
> Larry Gritz
> address@hidden