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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> If there aren't any comments on this then could it be merged? >>> >>> Ashley >>> From: Ashley Whetter <mailto:[email protected]> >>> Sent: 08/02/2016 14:05 >>> To: Larry Gritz <mailto:[email protected]> >>> Cc: [email protected] [email protected] >>> <mailto:[email protected]> >>> 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:[email protected]> >>> Sent: 23/01/2016 17:26 >>> To: Ashley Whetter <mailto:[email protected]> >>> Cc: Piotr Stanczyk <mailto:[email protected]>; >>> [email protected] [email protected] >>> <mailto:[email protected]> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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:[email protected]> >>>> Sent: 23/01/2016 07:19 >>>> To: Larry Gritz <mailto:[email protected]> >>>> Cc: [email protected] [email protected] >>>> <mailto:[email protected]> >>>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >>>> >>> >>> -- >>> Larry Gritz >>> [email protected] <mailto:[email protected]> >>> >>> >> >> -- >> Larry Gritz >> [email protected] >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/openexr-devel > > -- Larry Gritz [email protected] _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
