On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell <brat...@opera.com> wrote:
> Den 2013-03-26 21:29:32 skrev Benjamin Poulain <benja...@webkit.org>: > >> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke <dpra...@chromium.org> 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. >> > > I guess you mean that it will be more job moving files around, but that is > a rather rare operation, while reading an include directive and wondering > what it's part of is rather common (both for compilers, tools and humans). > My personal issue with full path is I don't think of the code base in term of files but in terms of classes. I don't care where the files are, it is a detail. The problem of moving file is also obvious. There is already a huge cost associated with moving and renaming files (all the build systems). It is to the point that people will prefer leaving broken name rather than renaming headers. By having full path, you would increase that cost further, making refactoring even harder. > I like the paths as a tool to indicate "module" dependencies. You can more > easily see that a file depends on foo and bar (but not on fie) if you see: > #include "foo/object.h" > #include "foo/thing.h" > #include "bar/stuff.h" > > That will tell you useful things, and avoid making layering violations by > accident. > I don't understand this argument. We already have WTF, WebCore, WebKit and we use them as prefix when including headers. The last problem is platform. But it should be fixed by moving it outside WebCore, not by changing everything else. I think is already silly to have wtf/text as a weird exception. But I realize it's a question of style and as such there is not a right and > a wrong, unless there are other factors. And here we have the seemingly > heavy compilation time cost for it which I think is a strong argument > against delegating the task of finding the header files to the compiler. Hackabilty is a project goal. Compile time is not. If the change means people are afraid to move/rename files, it is a bad idea. If such a change comes with the appropriate tooling for moving/renaming files, I am not opposed to it. Benjamin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
