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

[Ashley Whetter]

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