[poppler] cmake issues

Sun Sep 17 22:47:15 UTC 2017

El dilluns, 18 de setembre de 2017, a les 8:03:09 CEST, Adrian Johnson va 
escriure:
> On 18/09/17 07:41, Albert Astals Cid wrote:
> > El dilluns, 18 de setembre de 2017, a les 7:37:35 CEST, Adrian Johnson va
> > 
> > escriure:
> >> On 18/09/17 04:19, Albert Astals Cid wrote:
> >>> El diumenge, 17 de setembre de 2017, a les 18:30:08 CEST, Adrian Johnson
> >>> va
> >>> 
> >>> escriure:
> >>>> On 06/09/17 03:03, Albert Astals Cid wrote:
> >>>>> El dimarts, 5 de setembre de 2017, a les 8:14:56 CEST, Adrian Johnson
> >>>>> va
> >>>>> 
> >>>>> escriure:
> >>>>>> On 05/09/17 06:39, Albert Astals Cid wrote:
> >>>>>>> El dilluns, 4 de setembre de 2017, a les 7:52:39 CEST, Adrian
> >>>>>>> Johnson
> >>>>>>> va
> >>>>> 
> >>>>> escriure:
> >>>>>>>> On 04/09/17 06:12, Albert Astals Cid wrote:
> >>>>>>>>> El diumenge, 3 de setembre de 2017, a les 14:24:16 CEST, Adrian
> >>>>>>>>> Johnson
> >>>>>>>>> va
> >>>>>>>>> 
> >>>>>>>>> escriure:
> >>>>>>>>>> I managed to get it working. See attached patch. The problem
> >>>>>>>>>> seems
> >>>>>>>>>> to
> >>>>>>>>>> be
> >>>>>>>>>> that pkg_check_modules does not return the absolute path of the
> >>>>>>>>>> shared
> >>>>>>>>>> libraries. There is a bug for this at
> >>>>>>>>>> https://cmake.org/Bug/view.php?id=15804.
> >>>>>>>>>> 
> >>>>>>>>>> Is there a better way to handle this?
> >>>>>>>>> 
> >>>>>>>>> That's a really weird patch, cna you tell me exactly how is your
> >>>>>>>>> setup
> >>>>>>>>> so
> >>>>>>>>> i
> >>>>>>>>> can try reproducing the problem you have?
> >>>>>>>> 
> >>>>>>>> Attached is a script to reproduce it. It downloads and installs the
> >>>>>>>> latest cairo development snapshot to a custom prefix. Then patches
> >>>>>>>> poppler to use the new API in this version of cairo and tries to
> >>>>>>>> build
> >>>>>>>> it.
> >>>>>>> 
> >>>>>>> Another fix is using this patch.
> >>>>>> 
> >>>>>> That works. Although I thought I tried that before. Probably also
> >>>>>> needs
> >>>>>> freetype listed as I sometimes build freetype from git.
> >>>>> 
> >>>>> Ok, i'll commit, let's add freetype if needed when you can try that
> >>>>> scenario, maybe it's not needed (don't know if gtk libraries pulls
> >>>>> freetype).
> >>>> 
> >>>> So now I've run into the same problem with freetype. Cairo 1.15.8 uses
> >>>> FT_Get_Var_Design_Coordinates() if freetype >= 2.8.0. With these
> >>>> versions of cairo and freetype installed to a custom location and
> >>>> PKG_CONFIG_PATH pointing at them, linking pdftocairo fails because
> >>>> poppler has found my custom built cairo but is linking with the system
> >>>> freetype.
> >>>> 
> >>>> I tried adding FREETYPE_LIBRARIES to the target_link_libraries but this
> >>>> did not work. The problem seems to be poppler is using find_package()
> >>>> to
> >>>> find freetype. But find_package() doesn't use pkg-config and finds the
> >>>> system freetype instead.
> >>> 
> >>> Have you tried using FREETYPE_DIR as suggested in
> >>> /usr/share/cmake-3.7/Modules/FindFreetype.cmake
> >>> ?
> >> 
> >> That works. See attached patch.
> > 
> > The idea is that you do that yourself, not from cmake, i.e.
> > 
> > cmake -DFREETYPE_DIR=/somewhere/over/the/rainbow
> 
> Seriously? That feels like the 1990's. Why is cmake treating pkgconfig
> as a second class citizen. With autotools it just worked.

If you think the FindFreetype.cmake should really obey pkgconfig you probably 
want to propose that upstream to cmake FindFreetype.cmake. CMake is released 
quite often and from what i can see much more open to patches than autotools.

Your patch has the problem of breaking people that are used to how cmake 
works, i.e. you can't specify FREETYPE_DIR anymore since it'll be overwriten.

Cheers,
  Albert

> 
> > Cheers,
> > 
> >   Albert
> >   
> >>> Cheers,
> >>> 
> >>>   Albert
> >>>> 
> >>>> I changed CMakeLists.txt to use pkg_check_modules to find freetype. Now
> >>>> it finds my custom freetype but still tries to link with the system
> >>>> freetype because it doesn't have the absolute path to the freetype
> >>>> library. Which is due to this bug
> >>>> https://cmake.org/Bug/view.php?id=15804.
> >>>> 
> >>>> The attached patch works for me. Is there a standard cmake way of
> >>>> handling pkg-config based libraries in non standard locations? I expect
> >>>> the same problem will occur with every pkg-config based library we use
> >>>> 
> >>>>> Cheers,
> >>>>> 
> >>>>>   Albert
> >>>>>   
> >>>>>>> Seems less bad than the last one you sent (which tbh i didn't
> >>>>>>> undestand
> >>>>>>> at
> >>>>>>> all), no?
> >>>>>> 
> >>>>>> I was trying to avoid listing both "-lcairo" and
> >>>>>> /path/to/my/libcairo.so
> >>>>>> in the linker command line. FindCairo.cmake was using find_library to
> >>>>>> get the absolute path while FindGTK.cmake was not.
> >>>>>> 
> >>>>>>> Cheers,
> >>>>>>> 
> >>>>>>>   Albert
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> poppler mailing list
> >>>>>>> poppler at lists.freedesktop.org
> >>>>>>> https://lists.freedesktop.org/mailman/listinfo/poppler
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> poppler mailing list
> >>>>>> poppler at lists.freedesktop.org
> >>>>>> https://lists.freedesktop.org/mailman/listinfo/poppler
> >>>>> 
> >>>>> _______________________________________________
> >>>>> poppler mailing list
> >>>>> poppler at lists.freedesktop.org
> >>>>> https://lists.freedesktop.org/mailman/listinfo/poppler
> >>> 
> >>> _______________________________________________
> >>> poppler mailing list
> >>> poppler at lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/poppler
> > 
> > _______________________________________________
> > poppler mailing list
> > poppler at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/poppler
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler