Summary: | WebKitAvailability.h has Mac-specific versioning | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alp Toker <alp> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | andersca, ap, christian, darin, laszlo.gombos, mrobinson, mrowe |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | |||
Bug Blocks: | 20232 |
Description
Alp Toker
2008-08-04 19:41:40 PDT
I'm open to suggestions, but rolling out the change without any concrete plan on how to improve the situation does not seem reasonable to me. We can revise this to work well across multiple platforms -- but I don't see the need to roll it out! It seems wrong to have this marked as a P1, since it's not causing any immediate problems for anyone. Maybe we should just put a Mac OS X or Apple prefix on these macros for now? (In reply to comment #2) > We can revise this to work well across multiple platforms -- but I don't see > the need to roll it out! It seems wrong to have this marked as a P1, since it's > not causing any immediate problems for anyone. > The immediate problem is that we don't want to freeze WebKit 1.0.2 for GTK+ with public API headers containing macros and documentation for WebKit 3.1 for Mac, so it is something of a blocker for the GTK+ port if nobody else. I can kick off discussion by suggesting a modification that would be consistent with the JS_EXPORT macros and other header names. We can rename WebKitAvailability.h to JSAvailability.h and change the macros like this: - JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) AVAILABLE_AFTER_WEBKIT_VERSION_3_1; + JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) AVAILABLE_AFTER_JS_VERSION_3_1; The problem here is that the x.y versioning scheme still doesn't offer enough granularity for us since the WebKit/Mac release schedule isn't public, so the macros won't be reliable for our developers. I'm sure we can find a technical solution that works for everyone (like say, a separate versioning scheme for the JavaScriptCore API that gets bumped by port maintainers). Until that time, I don't believe these changes should be in SVN. (In reply to comment #4) > (In reply to comment #2) > > We can revise this to work well across multiple platforms -- but I don't see > > the need to roll it out! It seems wrong to have this marked as a P1, since it's > > not causing any immediate problems for anyone. > > > > The immediate problem is that we don't want to freeze WebKit 1.0.2 for GTK+ > with public API headers containing macros and documentation for WebKit 3.1 for > Mac, so it is something of a blocker for the GTK+ port if nobody else. > > I can kick off discussion by suggesting a modification that would be consistent > with the JS_EXPORT macros and other header names. We can rename > WebKitAvailability.h to JSAvailability.h and change the macros like this: > > - JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) > AVAILABLE_AFTER_WEBKIT_VERSION_3_1; > + JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) > AVAILABLE_AFTER_JS_VERSION_3_1; This scheme wouldn't make sense for the uses of these macros in the WebKit API layer. This hasn't proved to be an issue for WebKitGTK+, so I think it's safe to close this bug and reopen it if we ever run into problems. |