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

[Larry Gritz]

I think I view the find_package to mostly be for low-hassle install of whatever latest packages are found as the system defaults. It's the "works ok everywhere" solution that you have to provide to prevent every new user from complaining that they can't get your package to build.

But for a production site that may have multiple versions of packages installed and are very particular about which versions they need, have custom namespaces or library names, and all other manner of historical ugliness, yeah, I tend to have some kind of override that spells it all out with site-specific paths. (As an example, check out this wrapper for OIIO build that is just for SPI: https://github.com/OpenImageIO/oiio/blob/master/site/spi/Makefile-bits-arnold )

I consider those to be two somewhat separate use cases, both essential, but with different requirements.

On Jan 25, 2016, at 10:23 AM, Christopher Horvath <address@hidden> wrote:

This may be counterproductive to share, but...

I've been working with production CMake installations for years - since beginning the Alembic project - and I have yet to get one to work completely correctly. I have resorted, almost exclusively, to simply hardcoding the locations of each of the libraries directly, and skipping the "FindPackage" step altogether.  After spending about 3 days trying to get the HDF5 Cmake file to actually correctly find the installation, I gave up.

I'm really curious to hear if anyone has gotten CMake to work for real in a complex production environment with multiple versions of things like boost, python, and so on.  I note that every large organization I've seen (such as Google, Facebook) just ports the builds to their proprietary build tools, rather than using autoconf or cmake.

Am I alone in my failure to get CMake to work the way it is intended?

Chris

On Sat, Jan 23, 2016 at 9:25 AM, Larry Gritz <address@hidden> wrote:

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

NVIDIA texture tools: 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

OpenSceneGraph: 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> wrote:

I've already implemented a FindIlmBase and FindOpenExr in this pull request: 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
Sent: ‎23/‎01/‎2016 07:19
To: Larry Gritz
Cc: address@hidden 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

Thanks

-Piotr

On 22 January 2016 at 23:10, Larry Gritz <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



_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
address@hidden

_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
address@hidden