[cmake-developers] cmake --find-package

Alexander Neundorf neundorf at kde.org
Thu Apr 24 16:41:58 EDT 2014


On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote:
> On 2014-04-23 22:40+0200 Alexander Neundorf wrote:
> > On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
> >> On 2014-04-23 13:21-0400 Bill Hoffman wrote:
> >>> On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
> >>>> However, if you discover the problem is a general one for
> >>>> --find-package and Qt5, then it appears that Qt5 might be a good
> >>>> illustrative example to use for your renewed effort at developing a
> >>>> reliable --find-package capability.
> >>> 
> >>> I recently ran into a project using --find-package and found a
> >>> limitation
> >>> that could be very problematic.  If a find module in CMake uses a
> >>> try-compile, or tries to figure out anything to do with the compiler,
> >>> this
> >>> command will fail.    I am not sure there is a good way around this.
> >>> Certainly try-compile is not actively discouraged in the CMake Modules,
> >>> so
> >>> this can be added to any module at any time, breaking --find-package in
> >>> the
> >>> future.
> >> 
> >> Hi Bill:
> >> 
> >> You cannot use --find-package unless you specify the language.  So I
> >> assume that --find-package enables the specified language, and, in
> >> general, you would think that try-compile would work properly under
> >> those circumstances.
> > 
> > No.
> > 
> > It doesn't really enable a language, it only loads a bunch of files to set
> > the most urgently required variables.
> > Most of it is implemented in CMakeFindPackageMode.cmake
> > 
> > It is basically wrapping a find_package() call, setting up just enough to
> > make it succeed usually.
> > try_compile() will fail.
> > 
> > My plan was to limit this mode to Config.cmake files only, but as I said,
> > due to the changes in CMake this has become too much work, so I won't
> > work on that in the forseeable future.
> 
> Hi Alex:
> 
> The question that remains is will --find-package be maintained
> indefinitely for CMake-3.x?  

I can't guarantee.
Since modern Config.cmake files don't follow the old convention of setting a 
_LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic assumption 
the --find-package feature was based on, I don't really feel motivated to fix 
this.

> As I said, --find-package is the only way
> I know how to obtain required compile and link flags for Qt5 at the
> present time (assuming the patch for the library name screwup is
> accepted for the CMake support files in Qt5, but that is a separate
> Qt5 issue compared to whether or not you decide to maintain
> --find-package for CMake-3.x).  Until I discovered this thread, I had
> assumed that the --find-package option would be maintained
> indefinitely for CMake so I haven't looked further at other
> alternatives yet.
> 
> Assuming you or someone else decides to remove the --find-package
> capability now or sometime during CMake-3.x (which from my point of
> view makes sense if you are not going to maintain it), 

I wouldn't object.
This is actually the first time I get serious feedback for that feature, I had 
the impression nobody uses it or considers it useful.

Alex




More information about the cmake-developers mailing list