On Feb 11, 2013, at 5:03 PM, Dirk Pranke wrote: > On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier <kev...@theolliviers.com> > wrote: >> >> On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: >> >>> On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier <kev...@theolliviers.com> >>> wrote: >>>> >>>> On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: >>>> >>>>> On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier <kev...@theolliviers.com> >>>>> wrote: >>>>> >>>>>> Actually, it will, if anything, increase the workload. Because I use >>>>>> waf, I am able to use Python to auto-generate the list of sources to >>>>>> build. In other words, I tell it to build all sources in a defined list >>>>>> of base source directories, along with all sources in >>>>>> baseDirectory/portName subdirs (where in this case I set portName to wx) >>>>>> and FileName<portName>.cpp (e.g. FileNameWX.cpp if the port is wx), >>>>>> along with some additional similar rules for USE defines, like CF. Then >>>>>> if there are exceptions to these rules, I just filter them out of the >>>>>> results or explicitly add files when I need to, say if I need to compile >>>>>> a single Mac port source file. Since the WebKit tree is well-structured, >>>>>> this approach works quite well, with me having to define exceptions >>>>>> fairly rarely. The main issue I run into seems to be derived sources >>>>>> files that are no longer built / used but are still being generated. The >>>>>> performance hit of this is about 1 added second to my build, though on >>>>>> slower ma chin >>>> es it might be a couple seconds. For me, it's negligible given the benefit >>>> I get from it. >>>>> >>>>> If I understand correctly, gyp is also capable of this kind of >>>>> wildcard inclusion and exclusion. This will be the tool that allows >>>>> the gyp build to be shared among many ports with the same source >>>>> lists. >>>> >>>> Yes, but that is not what I see when I check, say, >>>> Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in >>>> it over the past 6 months in comparison to the ~10 lines of changes to >>>> source files in my patch-in-progress. So while gyp itself might have that >>>> feature in it, for whatever reason, the WebKit projects do not utilize >>>> that feature right now, so in practice, a switch to gyp means a switch >>>> away from rule-based compilation. >>>> >>> >>> There's two different things going on here: ease of maintenance, and >>> reproducibility. Using wildcards in the (meta-)build file itself can >>> make things easier but make it harder to get reproducible builds since >>> you might accidentally include files in the tree you didn't want. >>> >>> When you're on a minority port, having wildcards certainly makes your >>> life easier because you don't have to track every change we make >>> explicitly, and it's probably easier for you to ensure you're doing >>> things correctly in your own checkouts, so you don't have to worry >>> about reproducibility as much. >> >> If the filesystem always follows clearly defined rules, then I'd argue that >> reproducibility would not be an issue, though. WebKit currently doesn't >> always, but the vast majority of times it does. The cases where it doesn't >> are few and far between, and I don't think fixes would be all that >> difficult. You can always create specific locations, like perhaps a Shared >> directory, for any special cases that should explicitly be added by more >> than one, but a subset of, ports, and can't be properly encapsulated into a >> feature or use define. (For example, the WhateverNone.cpp are one of the >> special exceptions I have to account for, and they could go in there.) > >> >> I think the concern is really that this approach seems 'implicit' rather >> than 'explicit'. With clear filesystem rules, though, it's not actually >> implicit. A file going into one of the directories listed as a primary build >> dir means it is to be built by all ports. So long as the project defines >> said rules, the act of putting it there is explicit, and expresses intent. >> This also, BTW, addresses the problem of old stuff being left in the tree. >> To remove it from the build, you have to remove it, so you can just leave it >> sitting in the tree for someone to stumble across later. (I'm pretty sure a >> number of the exceptions I define in waf are actually examples of this.) > > I'm not sure we're talking about the same sort of concerns. The case > I'm talking about when you have a makefile that says something like > SRCS=*.cpp. Then, I have to remember to save a local copy of a file as > foo.cpp.orig rather than foo_orig.cpp, and if I want to rename a file > I have to actually rename it rather than copy it (or at least remember > to delete it). > > I think you're talking more about conventions over which directories > contain files for each port?
Yes, that was what I was talking about. I tend to avoid making copies of files like what you describe so as not to clutter my local tree. If I'm going to make substantial or more experimental changes, I just move it onto a git branch so I can just wipe everything if it doesn't pan out. >> >>> On the other hand, if you were to convert to using the same gypi files >>> we were using, then you wouldn't have to track every change we make, >>> either; you'd get them for free. >> >> Yes, but this mechanism relies on WebKit's policies about fixing others' >> build systems to be effective. waf, on the other hand, removes that task >> almost entirely. Plus, see my other comments about all the other benefits of >> using a meta-build system. (And BTW, on that topic, in newer versions of waf >> there is even a "build system kit" that provides a starting point for >> building your own build system off of waf. :) > > I think you're misunderstanding what we're talking about when using a > single build system. When all ports are sharing a common list of files > that make up webcore (e.g., as a single variable containing a list of > files in WebCore.gypi), then adding or deleting a file (used by all > ports, which is the common case) from WebCore involves one change to > one list of files - it's a fixed amount of work regardless of the > number of ports or platforms we build. Yes, I think we're just crossing wires here. I understand your point about the benefit of consolidating build systems, my point was that with waf, I don't need to wait for that day to come nor rely on others to patch my project files until then. Once that day is here, I might change my mind, though again there are many other benefits of waf over the shared files issue. Thanks, Kevin > Of course if you are making changes that may be used differently from > port to port, you may have to do more work, it depends on the > specifics. > > -- Dirk _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
