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

[Larry Gritz]

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