I've typically had more success with the autoconf tools, once a certain level of familiarity is achieved that is.
Having said that, I would like to echo your sentiments around proprietary build systems inside of tech companies for projects such as this one. -Piotr On 25 January 2016 at 10:23, Christopher Horvath <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> Sent: 23/01/2016 07:19 >> To: Larry Gritz <[email protected]> >> Cc: [email protected] [email protected] >> <[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 >> >> Thanks >> >> -Piotr >> >> >> On 22 January 2016 at 23:10, Larry Gritz <[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] >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel > >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
