On 1/4/08, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Eric, > > I've done a quick review of the changes and am ready to merge. First > though some clarification, the old find .cmake files have entries for > checking OSGDIR and OSGROOT were checked, but not in your new changes. > Personally I don't have a problem with this as they aren't OSG > projects anyway, but though I'd raise this flag to double check that > this removal is what you intended. I can't image too many users > relying on the OSG env vars this way so I don't see it as a problem.
Oh, right. I think that was intentional. So I've been making the CMake authors antsy about the aggressive use of FIND (see below). So I think I removed the OSG specific variables from the non-OSG-specific dependencies so they only respond to their module specific environmental variables. This helps enhance selective targeting and helps avoid accidental clashing. The argument against putting too many unrelated/general paths is that CMAKE_PREFIX_PATH and CMAKE_(LIBRARY|INCLUDE)_PATH can/should handle the cases where different components are in the same areas. > Another item I wonder about is the use of several sets of FIND calls. > Is this the direction CMake are heading? Could the use of custom > macro simplify some of this? So the multiple FIND is a technique to override the default CMake search order. The CMake authors have let me know that they are very antsy when it comes to people overriding the search order. But I think I justified the case. The double-FIND technique is now in the documentation I think because of this, though I think the CMake authors are still squirmish about the idea. Basically, the reason to override in our case is so users can specify an alternative location for a component on a per-component basis. This was something that was prompted by the people doing automated builds, but had multiple installations on their computer of things (stable/unstable) so they needed to ensure components in non-standard locations were picked up first. That's what all the environmental variable stuff is for. CMAKE_PREFIX_PATH is being supported directly so that can be removed from the module in the near future. So at least the triple-find is reduced to a double-find. I don't know if this is the direction of CMake or not. I personally think it's very useful and it should be, but I don't many user bases have been too concerned with automated builds and non-standard locations. The macro is actually not a bad idea, but I would say you yourself shouldn't worry about refactoring the code too much. The real, long-term plan is to get these modules into the official CMake (which I've already done for the set I've given you) and then down the road when everybody likely has a version of CMake that has the modules included, ween OSG's build system off the local copies and use the official versions. This means OSG will no longer have to maintain the modules and can delete them from the code base. I do recommend encouraging the other module writers to consider submitting their modules to CMake for inclusion so we can eventually remove even more modules. Thanks, Eric _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
