On Mar 26, 2013, at 5:51 PM, Benjamin Poulain <benja...@webkit.org> wrote:
> 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. I think a script to do a project-global search-and-replace of <foo/Bar.h> with <fizz/Buzz.h> would do the trick. > > Benjamin > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
