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 <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 <blackenc...@gmail.com> > 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 <l...@larrygritz.com > <mailto:l...@larrygritz.com>> 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 > <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 <ash...@awhetter.co.uk >> <mailto:ash...@awhetter.co.uk>> 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:piotr.stanc...@gmail.com> >> Sent: 23/01/2016 07:19 >> To: Larry Gritz <mailto:l...@larrygritz.com> >> Cc: openexr-devel@nongnu.org openexr-devel@nongnu.org >> <mailto:Openexr-devel@nongnu.org> >> 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 <l...@larrygritz.com >> <mailto:l...@larrygritz.com>> 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 >> l...@larrygritz.com <mailto:l...@larrygritz.com> >> >> >> >> _______________________________________________ >> Openexr-devel mailing list >> Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >> > > -- > Larry Gritz > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org> > https://lists.nongnu.org/mailman/listinfo/openexr-devel > <https://lists.nongnu.org/mailman/listinfo/openexr-devel> > > -- Larry Gritz l...@larrygritz.com
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
