On Mon, Nov 21, 2011 at 9:54 AM, Peter Kasting <[email protected]> wrote:
> On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar < > [email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
