[webkit-dev] Reg. New File Inclusion Style for Webkit

[Yuta Kitamura]

On Mon, Nov 21, 2011 at 9:54 AM, Peter Kasting <pkasting at google.com> wrote:

> On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar <
> ararunprasad at gmail.com> wrote:
>
>> Why don't we follow chrome style of file inclusions rather than the usual.
>>
>> For example,
>> *#include "WebCore/Page/Chrome.h"*
>>
>> This will be more convient way of representing the inclusion. Hope it
>> will avoid long compiler inclusion paths and file namespace issues.
>
>
> Here are some pros and cons I can think of:
>
> Pros:
> * If used pervasively, would allow us to greatly trim the compiler include
> search paths, possibly providing a noticeable build speedup (I have no
> estimated numbers).
> * Makes it slightly more obvious to a reader what, precisely, is being
> depended upon; might make it easier to notice layering violations.
>

One more pro:
* We would be able to use header files having the same name (located in
different directories or projects).
Right now, we can't add a header file having the same name as an existing
header file, even if it is located in a different project; I have seen this
in https://bugs.webkit.org/show_bug.cgi?id=72016.


>
> Cons:
> * Would require us to convert the existing codebase (possibly easy with
> the help of a script, but would at least result in touching all the files)
> * Generates more "change noise" when a header is moved around
> * Could pose problems for ports that need to supply particular headers
> from some override directory instead of the "typical" spot.  (I'm being
> vague here because I think this is probably a real issue but I don't
> actually know the details of enough ports' build setups to be
>
clear.)
>

For example, there are six separate files named ResourceRequest.h under
WebCore/platform/network. This header is only refered as
"ResourceRequest.h" and thus we would need to work around cases like this.

We would be able to fix this by adding a "dispatching" header file whose
content looks like:

#if USE(CF)
#include "WebCore/platform/network/cf/ResourceRequest.h"
#elif USE(CURL)
#include "WebCore/platform/network/curl/ResourceRequest.h"
#elif ...
....
#endif

... but the conversion would be boring. (maybe we could automate this?)

In WebCore, the following 48 header files are located at two or more places:

$ find . -name '*.h' -exec basename {} \; |sort |uniq -d
AuthenticationChallenge.h
DOMWrapperWorld.h
DownloadBundle.h
FontCustomPlatformData.h
FontPlatformData.h
IDBBindingUtilities.h
JavaScriptCallFrame.h
JNIUtilityPrivate.h
JPEGImageDecoder.h
JPEGImageEncoder.h
MediaPlayerProxy.h
npruntime_impl.h
npruntime_priv.h
OptionsObject.h
PageScriptDebugServer.h
PasteboardHelper.h
PlatformSupport.h
PNGImageEncoder.h
ResourceError.h
ResourceRequest.h
ResourceResponse.h
ScheduledAction.h
ScriptCachedFrameData.h
ScriptCallStackFactory.h
ScriptController.h
ScriptDebugServer.h
ScriptEventListener.h
ScriptFunctionCall.h
ScriptGCEvent.h
ScriptHeapSnapshot.h
ScriptInstance.h
ScriptObject.h
ScriptProfile.h
ScriptProfileNode.h
ScriptProfiler.h
ScriptSourceCode.h
ScriptState.h
ScriptValue.h
ScriptWrappable.h
SerializedScriptValue.h
SocketStreamError.h
SocketStreamHandle.h
SoftLinking.h
WebCoreSystemInterface.h
WebCoreTestSupport.h
WebScriptObject.h
WorkerScriptController.h
WorkerScriptDebugServer.h



>
> I would prefer the full-path style myself, especially if there is really a
> build-time win, but I strongly suspect that a lot of folks would see the
> benefit here as not worth the cost.
>
> PK
>

Agreed, converting conflicting header files seems like a lot of work to me.
I personally like the full-path style, though.

Thanks,
Yuta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111205/3f8e9eba/attachment.html>