<rdar://problem/4885130> mentions that the plan was to have applications include JSStringRefCF.h as needed, which sounds like the right thing to do, but r21342 goes against that.
I'm investigating switching a couple of bindings from the C++ API to the new C API. This is the only issue that's come up so far.
On other platforms, it might work better to include the appropriate headers individually.
(In reply to comment #1)
> header" that any Mac OS X framework has, which includes all its other headers.
> I don't suggest using it on other platforms. WebKit.h is the same way.
> has shipped with it as public API.
> On other platforms, it might work better to include the appropriate headers
(In reply to comment #4)
> The two header files (JSNodeList.h and JSNode.h) that do include
APICast.h JSContextRef.cpp JSStringRef.cpp
JSBase.cpp JSNode.c JSValueRef.cpp
JSBase.h JSNode.h JSValueRef.h
JSCallbackConstructor.cpp JSNodeList.c minidom.c
JSCallbackConstructor.h JSNodeList.h minidom.html
JSCallbackFunction.cpp JSObjectRef.cpp minidom.js
JSCallbackFunction.h JSObjectRef.h Node.c
JSCallbackObject.cpp JSRetainPtr.h Node.h
JSCallbackObjectFunctions.h JSStringRefBSTR.cpp NodeList.c
JSCallbackObject.h JSStringRefBSTR.h NodeList.h
JSClassRef.cpp JSStringRefCF.cpp testapi.c
JSClassRef.h JSStringRefCF.h testapi.js
Files used only when compiling WebKit:
(Keep in mind that the goal is not just to provide a similar API on Windows, Mac and Linux but to make it identical, so software builds and runs out of the box on each of these platforms as long as it's careful with platform dependencies.)
Why would "code written on non-Mac which does not use or expect to pull in CF break when you attempt to compile it on a Mac"?
(In reply to comment #8)
> Why would "code written on non-Mac which does not use or expect to pull in CF
> break when you attempt to compile it on a Mac"?
It seemed to me that implicitly pulling CF headers into an application using GLib or Qt may cause trouble. Perhaps it wouldn't. My understanding of best portability practices is that it's good to avoid this kind of situation.
Holger mentioned that C++-style comments "//" aren't accepted by some C compilers (he mentioned MSVC but I don't remember that being the case). There are some comments like this in the API headers.
If this turns out to be an issue, we might want to change those comments to increase portability. Does anyone have the facts on this?
Created attachment 18314 [details]
Comment on attachment 18314 [details]
Looks fine. r=me
Landed in r29234.
(In reply to comment #2)
> JSStringRefCF.h in a #ifdef of some type and have the build systems filter
> for the target platform.
I think this is the better approach to fixing this. The patch landed and broke the Mac build.
(In reply to comment #14)
I guess because Safari for Windows with CF....
Checking __APPLE__ isn't a great idea since it could limit developers using configurations we haven't considered yet (eg. CF on Linux). Better to keep it simple and require explicit includes, but if this isn't an option, my patch is probably the best compromise.
(In reply to comment #16)
> require applications to include JSStringRefCF.h, JSStringRefBSTR.h or the
> GLib/Qt equivalents as needed.
> Checking __APPLE__ isn't a great idea since it could limit developers using
> configurations we haven't considered yet (eg. CF on Linux). Better to keep it
> simple and require explicit includes, but if this isn't an option, my patch is
> probably the best compromise.
Yes, agreed. But we need a version of your patch that doesn't break Mac OS X. Tim took care of that now.
Nice build fixing. Thanks timothy and aroben.
I wonder though if the Mac build should use ForwardingHeaders for the JSC API like the GTK+ build. This would help keep minidom buildable out-of-tree against the system-installed SDK (since it's a nice code sample for people learning the API to try building themselves).