[webkit-dev] Is the wxWidgets port maintained?

[Kevin Ollivier]

On Feb 11, 2013, at 5:03 PM, Dirk Pranke wrote:

> On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier <kevino at 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 <kevino at 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 <kevino at 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 machin
>>>> 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