4 июл. 2017 г. 3:19 ПП пользователь "Landry Breuil" <lan...@openbsd.org>
написал:
On Tue, Jul 04, 2017 at 01:21:48PM +0300, Vadim Zhukov wrote:
> >>
> >>
> >> But that's of course ugly, so i'm looking for help to figure out if
this
> >> is a problem in FindLibxml2.cmake or in pgpointcloud's CMakeLists.txt..
> >>
> >
> > It's definitely not a FindLibxml2.cmake problem because
> > "find_package(LibXml2)" works fine with akonadi-17.04.1 (kf5 port on
> > openbsd-wip).
>
> It's definitely the FindLibXml2.cmake problem, since it doesn't
> provide LIBXML2_INCLUDE_DIRS (notice the 'S'), and only
LIBXML_INCLUDE_DIR.
> This should be fixed upstream with patch like below; I'll need to recover
> my Kitware account password, though... :)
>
> After that applied, you'll need to tweak the pgpointcloud port to use
> the ${LIBXML2_INCLUDE_DIRS} instead of ${LIBXML2_INCLUDE_DIR}.
But is the S that important in the name, is cmake doing a different
magic if the variable ends up with DIRS instead of DIR ?
How come it 'probably works' on other oses ?
There is no magic in DIRS, or DIR either, it's just a de-facto standard in
CMake world that Foo_INCLUDE_DIR talks about Foo itself (and is cached in
CMakeCache.txt), while Foo_INCLUDE_DIRS talks about Foo and public
dependencies (those required to build using Foo), and this value should not
be cached. All new CMake FindFoo.cmake modules should follow that scheme,
but older ones are not forced to change. My proposal is
backward-compatible, so I think it would be accepted upstream.
Things likely work on Linux because libxml2's dependencies live in
/usr/include, which is already in compiler search path.
