Re: [webkit-dev] Reg. New File Inclusion Style for Webkit
yes, this will yield a good results for build time. I would like to get more comments from other developers regarding this. On 21 November 2011 06:24, Peter Kasting pkast...@google.com wrote: On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar ararunpra...@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. 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.) 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reg. New File Inclusion Style for Webkit
I don't think we want to do this. We move files around quite often, and specifying relative path will make it harder to do so as Peter pointed out. - Ryosuke On Sun, Dec 4, 2011 at 2:02 AM, Arunprasad Rajkumar ararunpra...@gmail.comwrote: yes, this will yield a good results for build time. I would like to get more comments from other developers regarding this. On 21 November 2011 06:24, Peter Kasting pkast...@google.com wrote: On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar ararunpra...@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. 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.) 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reg. New File Inclusion Style for Webkit
On Mon, Nov 21, 2011 at 9:54 AM, Peter Kasting pkast...@google.com wrote:
On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar
ararunpra...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reg. New File Inclusion Style for Webkit
On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar ararunpra...@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. 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.) 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
