Bug 135288 - [GTK] CMake tries to install JavaScriptCore-3.0.gir outside of install prefix
Summary: [GTK] CMake tries to install JavaScriptCore-3.0.gir outside of install prefix
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-25 08:21 PDT by Michael Catanzaro
Modified: 2014-08-14 02:01 PDT (History)
6 users (show)

See Also:


Attachments
Patch (4.70 KB, patch)
2014-07-25 08:29 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2014-07-25 08:21:21 PDT
I'm trying to install WebKit into an install prefix in my home directory, calling CMake manually rather than with the build-webkit script:

cmake /home/mcatanzaro/WebKit -DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/mcatanzaro/jhbuild/install -DLIB_INSTALL_DIR=/home/mcatanzaro/jhbuild/install/lib -GNinja

But CMAKE_INSTALL_PREFIX is not respected when installing JavaScriptCore-3.0.gir; it's unconditionally installed into /usr/share because FindGObjectIntrospection.cmake uses pkgconfig to decide where to install to, and that's what pkgconfig says to do:

# /usr/lib64/pkgconfig/gobject-introspection-1.0.pc
datadir=/usr/share
...
girdir=${datadir}/gir-1.0

FindGObjectIntrospection.cmake tries to define the prefix variable, but it's not actually used by gobject-introspection-1.0.pc since $datadir was set to /usr/share by my distro (Fedora) at configure time (I think all RPM-based distros will do this). So this can never work.

The upcoming patch fixes this error from the user's perspective, but makes FindGObjectIntrospection.cmake depend on variables set in OptionsGTK.cmake, which I'm worried is probably evil. I don't know what else to do, though.
Comment 1 Michael Catanzaro 2014-07-25 08:29:28 PDT
Created attachment 235520 [details]
Patch
Comment 2 Martin Robinson 2014-07-25 08:43:28 PDT
Comment on attachment 235520 [details]
Patch

Seems entirely reasonable
Comment 3 WebKit Commit Bot 2014-07-25 09:18:37 PDT
Comment on attachment 235520 [details]
Patch

Clearing flags on attachment: 235520

Committed r171598: <http://trac.webkit.org/changeset/171598>
Comment 4 WebKit Commit Bot 2014-07-25 09:18:40 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 Carlos Garcia Campos 2014-08-14 02:01:13 PDT
Comment on attachment 235520 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=235520&action=review

> Source/cmake/FindGObjectIntrospection.cmake:48
> -        _gir_get_pkgconfig_var(INTROSPECTION_INSTALL_GIRDIR "girdir" "--define-variable=prefix=${CMAKE_INSTALL_PREFIX}")
> -        _gir_get_pkgconfig_var(INTROSPECTION_INSTALL_TYPELIBDIR "typelibdir" "--define-variable=prefix=${CMAKE_INSTALL_PREFIX}")
> +        _gir_get_pkgconfig_var(INTROSPECTION_INSTALL_GIRDIR "girdir" "--define-variable=datadir=${DATA_INSTALL_DIR}")
> +        _gir_get_pkgconfig_var(INTROSPECTION_INSTALL_TYPELIBDIR "typelibdir" "--define-variable=libdir=${LIB_INSTALL_DIR}")

This is indeed wrong, we want to install the introspection stuff in the standard location together with the other gir and typelibs. DATA_INSTALL_DIR is also versioned, but gir and typelibs doesn't need to be installe din a versioned directory because their filenames already contain the binary version. But the previous code was not correct in my opinion either. We need to get the introspection tools from the pkg-configl file because they might not  be in the path, we definitely don't want to get the girdir and typelibdir from the pkg-config file, because that would mean that if I'm using gobject-instrospection from my distro, but building in muy jhbuild, we would end up trying to install introspection files to /usr. I guess this bug was about that. In autotools we defined both dirs unconditionally depending on $datadir and $libdir.