Also keep in mind that currently different build systems hack the include path up to have the same #include point to different headers depending on the build configuration, so the path expansion for a given #include will not be the same for all ports. It's basically a very non-obvious way to do #if PLATFORM() guards at include sites without looking like it. For instance there are 7 different versions of AuthenticationChallenge.h but only one #include statement in ResourceLoader.cpp.
Consider: $ find Source/WebCore -name "*.h" -printf "%f\n" | wc -l 3383 $ find Source/WebCore -name "*.h" -printf "%f\n" | sort | uniq | wc -l 3288 - James On Tue, Mar 26, 2013 at 1:40 PM, Dirk Pranke <[email protected]> wrote: > On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain <[email protected]>wrote: > >> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke <[email protected]> wrote >> >>> If we have consensus that we should just switch to paths relative to >>> Source (or maybe a couple different options), that would be (IMO) a big >>> win. It sounds like Daniel & co. have already done the big bang conversion. >>> >> >> I think using full path would be a serious hit regarding hackability. >> >> I would rather spend some time tweaking my compiler to cache each >> directory content than waste time finding where is every single header I >> need to include. >> >> > Interesting. I have the exact opposite experience, having to paw around to > figure out where "Font.h" actually lives rather than just seeing > "WebCore/platform/graphics/Font.h". > > At any rate, to be clear, I would be in favor of that change but I'm not > expecting it to happen :). > > -- Dirk > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
