Bug 435561
Summary: | Header file <> header file location mismatch | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> |
Component: | WebKit | Assignee: | Peter Gordon <peter> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | erik-fedora |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 1.0.0-0.6.svn30667 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-03-05 04:22:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 435562 |
Description
Mamoru TASAKA
2008-03-01 18:21:16 UTC
Hmm. The pkgconfig files reference the include directory as "WebKit" so I'll have to patch those headers a bit. I'll get to this after some food. :) Thanks for the bug report! I believe this is fixed with tomorrow's Rawhide (1.0.0-0.6.svn30667.fc9). Please re-open this bug with further details if the issue persists. Thanks. On Gentoo they are using svn 30468 of WebKit and the package is build using the plain old ./configure method (no qmake) without any additional scripting (only the GTK part is build). The resulting files from this build differ from what's now in Fedora. First of all, the pkgconfig file, /usr/lib/pkgconfig/WebKitGtk.pc doesn't exist, but a new file, named /usr/lib/pkgconfig/webkit-1.0.pc is. The contents of this file are : -- prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: WebKit Description: Web content engine for GTK+ applications Version: 0.1 Requires: gtk+-2.0 Libs: -L${libdir} -lWebKitGtk Cflags: -I${includedir}/WebKit -- Also, The webkit*.h headers from the WebKit-gtk package are all placed in /usr/include/WebKit/webkit, not in /usr/include/webkit : $ls /usr/include/WebKit/webkit/ webkitdefines.h webkit.h webkitnetworkrequest.h webkitwebbackforwardlist.h webkitwebframe.h webkitwebhistoryitem.h webkitwebsettings.h webkitwebview.h This makes it difficult for developers which want to use WebKit to develop software as there are differences between the distro's. Maybe it would be better if you could ask upstream which direction they want to go with the naming and placement of the pkgconfig file and the headers, so all the distro's can adapt to the same layout. (In reply to comment #3) > On Gentoo they are using svn 30468 of WebKit and the package is build using the > plain old ./configure method (no qmake) without any additional scripting (only > the GTK part is build). In Fedora's build, both the Qt *and* GTK+ ports are built, so this qmake invoking is necessary. > The resulting files from this build differ from what's now in Fedora. First of > all, the pkgconfig file, /usr/lib/pkgconfig/WebKitGtk.pc doesn't exist, but a > new file, named /usr/lib/pkgconfig/webkit-1.0.pc is. > > The contents of this file are : > [...] This file rename is due to the use of autotools instead of qmake. Thus, since Gentoo uses autotools (and builds only the GTK+ port), the pkgconfig file is changed. > Also, The webkit*.h headers from the WebKit-gtk package are all placed in > /usr/include/WebKit/webkit, not in /usr/include/webkit : > [...] > This makes it difficult for developers which want to use WebKit to develop > software as there are differences between the distro's. > The include directory should not matter. Anything that needs to build against it should be calling pkg-config to find the headers location; and so long as the pkgconfig data is correct, the build should succeed...in theory. I have based my WebKit packaging on that of Debian/Ubuntu (which build both ports, versus Gentoo's GTK-only build), so I believe it to be sufficiently consistent in terms of cross-distro compatibility. However, if this does pose a problem in the future, please let me know and I will attempt to work with the upstream devs so that it can be resolved appropriately. Thanks. |