[CMake] Suggesting to FindQT4.cmake where to find QT4

Adolfo Rodríguez dofo79 at gmail.com
Fri May 29 05:43:39 EDT 2009


On Fri, May 29, 2009 at 10:53 AM, Jed Brown <jed at 59a2.org> wrote:

> Adolfo Rodríguez wrote:
> > On Fri, May 29, 2009 at 5:48 AM, Clinton Stimpson <clinton at elemtech.com
> >wrote:
>
> >> I think what is being asked here is a good idea.  There is already
> >> the CMAKE_PREFIX_PATH which gives find_package(Qt4) a prefix to work
> >> from.  If I set it to one of my other Qt4, directories, it finds that
> >> Qt installation fine.  But maybe adding something like a
> >> QT4_PREFIX_PATH to have find_package(Qt4) prefer another directory
> >> first and MPI_PREFIX_PATH to have find_package(MPI) prefer yet a
> >> different directory would be nice.
>
> MPIHOME is a pseudo-standard here, but I agree.
>
> >> Maybe even extend that so if one did
> >> find_program(MYVAR_EXECUTABLE ...)
> >> find_library(MYVAR_LIBRARY ...)
> >> a user of a CMakeLists.txt file containing that could set
> >> MYVAR_PREFIX_PATH.
> >>
> >> Or maybe use MYVAR_DIR so the same variable works when cmake config
> files
> >> are found by find_package().
> >>
> >> Maybe another step would be to detect if MYVAR_DIR changed, and remove
> all
> >> dependent variables and do a re-find.
> >>
> >> I see that FindBoost.cmake has a BOOST_ROOT that tries to do the above,
> but
> >> a standard mechanism for all find_* would be better.
>
> It looks like FindBoost tries to respect environment variables, but
> doesn't try to recover if BOOST_ROOT changes.  For that, you need the
> sort of logic in FindQt4 (QT_QMAKE_CHANGED) or in my modules (FindPETSc,
> etc).  It's remarkable frustrating to make robust.
>
> >> Or does cmake already have a standard way of doing this?
>
> Not that I know of, see
>
>
> http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Dependent_cache_variables
>
> > I do something like this when looking for simple packages (thanks to Greg
> > Peele for a cool tip on this):
> >
> > # Get hint from environment variable (if any)
> > if(DEFINED ENV{FOO_ROOT_DIR})
> >   set(FOO_ROOT_DIR "$ENV{FOO_ROOT_DIR}" CACHE PATH "FOO base directory
> > location (optional, used for nonstandard installation paths)" FORCE)
> >   mark_as_advanced(FOO_ROOT_DIR)
> > endif()
>
> This is bad because if the user had a messy environment, the
> FOO_ROOT_DIR will be set to the wrong value.  They will edit this value
> in cmake-gui and it will be wiped out when they press Configure.  They
> will have to quit cmake-gui and fix their environment to deal with this.
> In other words, it should not be FORCE and FOO_ROOT_DIR should not be
> advanced (it's the intended way for the user to interact with the find
> process, so users need to know that it exists).
>
> > # Search path for nonstandard locations
> > if(FOO_ROOT_DIR)
> >   set(FOO_INCLUDE_PATH PATHS ${FOO_ROOT_DIR}/include NO_DEFAULT_PATH)
> >   set(FOO_LIBRARY_PATH PATHS ${FOO_ROOT_DIR}/lib NO_DEFAULT_PATH)
> > endif()
> >
> > # Find headers and libraries
> > find_path(FOO_INCLUDE_DIR NAMES foo/FOO.h ${FOO_INCLUDE_PATH})
> > find_library(FOO_LIBRARY NAMES FOO ${FOO_LIBRARY_PATH})
>
> FOO_INCLUDE_DIR and FOO_LIBRARY will not be updated if the user changed
> FOO_ROOT_DIR, thus creating an inconsistent build.  Without language
> support, FindFoo needs to internally cache the last value of
> FOO_ROOT_DIR in order to detect if it has changed.  If so,
> FOO_INCLUDE_DIR, FOO_LIBRARY, and FOO_FOUND need to be FORCE cleared
> before they are searched for again.  This reset needs to include all
> internal variables, such as those used by CHECK_C_SOURCE_RUNS
> (${VAR}_COMPILED and ${VAR}_EXITCODE) because these checks need to be
> re-run.  As you can see, this crosses module boundaries and is a lot of
> work to maintain.


First of all, I apologize if the thread content drifted from its original
subject.
So, to do things right we have to carefully take into account all of these
factors. Apart from having popped in the ML a couple of times, is there a
link documenting in detail such
best practices? What cmake extensions (helper modules) -if any- would be
necessary to simplify the process?

Thanks in advance,

Adolfo


>
> Jed
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090529/c8e5a232/attachment.htm>


More information about the CMake mailing list