[Webkit-unassigned] [Bug 220636] New: [GTK] Multilib conflicts in gir files

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220636

            Bug ID: 220636
           Summary: [GTK] Multilib conflicts in gir files
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org

Our generated gir files currently include absolute paths. This is a problem for multilib because the gir files need to be identical on all architectures, since they are installed under /usr/share, but distro build directory names often vary based on architecture. For example, the top of JavaScriptCore-4.0.gir:

<?xml version="1.0"?>
<!-- This file was automatically generated from C sources - DO NOT EDIT!
To affect the contents of this file, edit the original C definitions,
and/or use gtk-doc annotations.  -->
<repository version="1.2"
            xmlns="http://www.gtk.org/introspection/core/1.0"
            xmlns:c="http://www.gtk.org/introspection/c/1.0"
            xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
  <include name="GObject" version="2.0"/>
  <package name="javascriptcoregtk-4.0"/>
  <c:include name="jsc/jsc.h"/>
  <namespace name="JavaScriptCore"
             version="4.0"
             shared-library="libjavascriptcoregtk-4.0.so.18"
             c:identifier-prefixes="JSC"
             c:symbol-prefixes="jsc">
    <function-macro name="CHECK_VERSION"
                    c:identifier="JSC_CHECK_VERSION"
                    introspectable="0">
      <source-position filename="x86_64-redhat-linux-gnu/DerivedSources/JavaScriptCore/javascriptcoregtk/jsc/JSCVersion.h"
                       line="67"/>

So the problem is clear: on i686, the <source-position filename="i686-redhat-linux-gnu" instead. This was not a problem in the past due to downstream build reasons: we had been creating our own build directory, but now the CMake RPM macro creates the build directory for us and includes the target arch in the name of the build directory.

Anyway, this is easy to fix pas passing --sources-top-dirs to g-ir-scanner. Then we get this instead:

      <source-position filename="DerivedSources/JavaScriptCore/javascriptcoregtk/jsc/JSCVersion.h"
                       line="67"/>

Much better!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210114/b01527c3/attachment.htm>