Re: [webkit-dev] Media Server Development

[Kiran K]

Thanks I will try webkit-help
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] MIPS review requests

[Gergely Kis]

Dear WebKit Developers,

Thank you for your support in getting LLINT for MIPS accepted into trunk.

There are still a few patches that need review in order to get webkit trunk
running on MIPS:

1. DFG JIT: https://bugs.webkit.org/show_bug.cgi?id=101328
We did the changes requested by the reviewers. Actually we did 2 versions
of the patch so you can choose which one you like best. Unfortunately we
did not get any reviews since then.

2. 64bit atomic implementation:
https://bugs.webkit.org/show_bug.cgi?id=106739
We implemented 64bit atomic increment and decrement using a mutex.
Unfortunately on MIPS there is currently no better solution. The same
solution is used on Android as well. Unfortunately we did not get any more
reviews on this issue either.

3. We also have another pending patch, which is not MIPS specific, but a
fix to the style checker which should help anyone who is submitting patches
with asm() statements:
https://bugs.webkit.org/show_bug.cgi?id=101367

This patch has also attracted no review comments so far.

Could anyone please help us in getting these patches reviewed, and
(hopefully) accepted into webkit trunk?

Thank you,
Gergely
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Hajime Morrita]

On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa  wrote:

> On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
>
>> The history aside, I think it makes sense to use the export macro
>> specifically for Mac WebCore because
>>
>> - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
>> separation.
>>   Other ports like GTK or Chromium build single "WebKit" library which
>> has both WebCore and WebKit API included.
>>   So we need to care about only Mac and Win for now.
>>
>> - Mac WebKit has relatively comprehensive feature set. It covers most of
>> possibly exported symbols.
>>
>> - The Windows toolchain allows us to use both export symbols list and
>> source-level annotation (the macro).
>>   Thus on Windows, we could use the Mac-centered export macro *and* an
>> export symbol list which covers Win-specific exports.
>>
>>   This means that there are unused exports on Win build, but I believe it
>> is very few considering that Mac/Win ports has
>>   similar feature set, which targets Safari on each platform. (This might
>> be wrong assumption though - On Mac, there are
>>   many other WebKit embedder other than Safari.)
>>
>> One exception is symbols exported for WebCoreTesting.
>> Fortunately, these symbols are exactly same across ports and we can use
>> another macro like
>> WEBCORE_TESTING_EXPORT for that.
>>
>
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular,
> I thought all symbols used in Internals need to be exported there.
>

Ouch, I'm sorry for the unclear explanation.
This is what I meant say as "one exception" above. WebCoreTesting includes
Internals, which requires some exported symbols,
which could be (IMO) covered by WEBCORE_TESTING_EXPORT or some separate
macro.


> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Martin Robinson]

On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
> thought all symbols used in Internals need to be exported there.

WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
because WebCore is built as a static convenience library. We do need
to export symbols for the Internals library because it's built as a
separate object that links against libwebkitgtk. Adding an export
macro for Internals would be great for us, since we wouldn't have to
export so many symbols via Source/autotools/symbols.filter. It would
also decrease the maintenance burden for non-GTK+ port contributors.

--Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:

> The history aside, I think it makes sense to use the export macro
> specifically for Mac WebCore because
>
> - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
> separation.
>   Other ports like GTK or Chromium build single "WebKit" library which has
> both WebCore and WebKit API included.
>   So we need to care about only Mac and Win for now.
>
> - Mac WebKit has relatively comprehensive feature set. It covers most of
> possibly exported symbols.
>
> - The Windows toolchain allows us to use both export symbols list and
> source-level annotation (the macro).
>   Thus on Windows, we could use the Mac-centered export macro *and* an
> export symbol list which covers Win-specific exports.
>
>   This means that there are unused exports on Win build, but I believe it
> is very few considering that Mac/Win ports has
>   similar feature set, which targets Safari on each platform. (This might
> be wrong assumption though - On Mac, there are
>   many other WebKit embedder other than Safari.)
>
> One exception is symbols exported for WebCoreTesting.
> Fortunately, these symbols are exactly same across ports and we can use
> another macro like
> WEBCORE_TESTING_EXPORT for that.
>

Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
thought all symbols used in Internals need to be exported there.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Darin Fisher]

It would be nice if, in the shared library build of chromium, webcore and
perhaps the modules and platform were separate DLLs.
On Jan 31, 2013 4:15 PM, "Eric Seidel"  wrote:

> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a defined set of
> platform APIs and callbacks which it talks to (which should be the
> exact same for every embedder).
>
> (The export dependency dates back to the WebCore/WebKit separation,
> which in my recollection was done largely to be able to isolate LGPL
> code from the non-LGPL Mac WebKit layer.)
>
> But I believe it is a mistake that WebCore changes need to care about
> the possibility that different ports may export functions differently,
> or even worse, that different ports may need a different set of
> functions exported.
>
> I don't recommend using a more complicated export macro, but rather
> finding ways that WebCore doesn't need to care about diverging sets of
> exports.
>
> I believe most ports (with the exception of AppleWin/AppleMac) do not
> build WebCore as a separate dynamic library from WebKit, which makes
> exports a non-concern in the static case.
>
> In my perfect future world, WebCore would be split into many static
> libraries, and core-code -> WebKit exports would be a non-issue.  And
> of course, no embedder of core-code would ever expose core types, so
> no exports would ever need to be marked.
>
>
> On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> I don't have concrete examples, and I don't know how big an effect on
> performance increasing the number of exports would have. It's something to
> keep an eye on, not a reason to avoid trying.
> >>
> >> I'm not parsing your reply properly -- avoid trying what? A common
> >> EXPORT macro that is set as appropriate by each port?
> >
> > Yes, you are parsing it correctly :)
> >
> > - WBR, Alexey Proskuryakov
> >
> >
> > ___
> > 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Hajime Morrita]

The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because

- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
  Other ports like GTK or Chromium build single "WebKit" library which has
both WebCore and WebKit API included.
  So we need to care about only Mac and Win for now.

- Mac WebKit has relatively comprehensive feature set. It covers most of
possibly exported symbols.

- The Windows toolchain allows us to use both export symbols list and
source-level annotation (the macro).
  Thus on Windows, we could use the Mac-centered export macro *and* an
export symbol list which covers Win-specific exports.

  This means that there are unused exports on Win build, but I believe it
is very few considering that Mac/Win ports has
  similar feature set, which targets Safari on each platform. (This might
be wrong assumption though - On Mac, there are
  many other WebKit embedder other than Safari.)

One exception is symbols exported for WebCoreTesting.
Fortunately, these symbols are exactly same across ports and we can use
another macro like
WEBCORE_TESTING_EXPORT for that.

--
morrita

On Fri, Feb 1, 2013 at 9:14 AM, Eric Seidel  wrote:

> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a defined set of
> platform APIs and callbacks which it talks to (which should be the
> exact same for every embedder).
>
> (The export dependency dates back to the WebCore/WebKit separation,
> which in my recollection was done largely to be able to isolate LGPL
> code from the non-LGPL Mac WebKit layer.)
>
> But I believe it is a mistake that WebCore changes need to care about
> the possibility that different ports may export functions differently,
> or even worse, that different ports may need a different set of
> functions exported.
>
> I don't recommend using a more complicated export macro, but rather
> finding ways that WebCore doesn't need to care about diverging sets of
> exports.
>
> I believe most ports (with the exception of AppleWin/AppleMac) do not
> build WebCore as a separate dynamic library from WebKit, which makes
> exports a non-concern in the static case.
>
> In my perfect future world, WebCore would be split into many static
> libraries, and core-code -> WebKit exports would be a non-issue.  And
> of course, no embedder of core-code would ever expose core types, so
> no exports would ever need to be marked.
>
>
> On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> I don't have concrete examples, and I don't know how big an effect on
> performance increasing the number of exports would have. It's something to
> keep an eye on, not a reason to avoid trying.
> >>
> >> I'm not parsing your reply properly -- avoid trying what? A common
> >> EXPORT macro that is set as appropriate by each port?
> >
> > Yes, you are parsing it correctly :)
> >
> > - WBR, Alexey Proskuryakov
> >
> >
> > ___
> > 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Eric Seidel]

I believe that it's a design mistake for WebCore to need to know
anything about it's embedder, more than that there is a defined set of
platform APIs and callbacks which it talks to (which should be the
exact same for every embedder).

(The export dependency dates back to the WebCore/WebKit separation,
which in my recollection was done largely to be able to isolate LGPL
code from the non-LGPL Mac WebKit layer.)

But I believe it is a mistake that WebCore changes need to care about
the possibility that different ports may export functions differently,
or even worse, that different ports may need a different set of
functions exported.

I don't recommend using a more complicated export macro, but rather
finding ways that WebCore doesn't need to care about diverging sets of
exports.

I believe most ports (with the exception of AppleWin/AppleMac) do not
build WebCore as a separate dynamic library from WebKit, which makes
exports a non-concern in the static case.

In my perfect future world, WebCore would be split into many static
libraries, and core-code -> WebKit exports would be a non-issue.  And
of course, no embedder of core-code would ever expose core types, so
no exports would ever need to be marked.


On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov  wrote:
>
> 31.01.2013, в 15:15, Dirk Pranke  написал(а):
>
>>> I don't have concrete examples, and I don't know how big an effect on 
>>> performance increasing the number of exports would have. It's something to 
>>> keep an eye on, not a reason to avoid trying.
>>
>> I'm not parsing your reply properly -- avoid trying what? A common
>> EXPORT macro that is set as appropriate by each port?
>
> Yes, you are parsing it correctly :)
>
> - WBR, Alexey Proskuryakov
>
>
> ___
> 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

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Alexey Proskuryakov]

31.01.2013, в 15:15, Dirk Pranke  написал(а):

>> I don't have concrete examples, and I don't know how big an effect on 
>> performance increasing the number of exports would have. It's something to 
>> keep an eye on, not a reason to avoid trying.
> 
> I'm not parsing your reply properly -- avoid trying what? A common
> EXPORT macro that is set as appropriate by each port?

Yes, you are parsing it correctly :)

- WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Dirk Pranke]

On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov  wrote:
>
> 31.01.2013, в 14:57, Dirk Pranke  написал(а):
>
>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>> the number of exports for each port, because it would export symbols that
>> are only needed for other ports.
>

 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?
>>>
>>> The latter.
>>>
>>> I suspect that it's somewhat less of an issue for JavaScriptCore, because 
>>> its exports are mostly used from cross-platform code.
>>>
>>
>> I see. Some concrete examples would be helpful here (to me, at least).
>> What components and ports are we talking about, and what sorts of
>> symbols?
>
> I don't have concrete examples, and I don't know how big an effect on 
> performance increasing the number of exports would have. It's something to 
> keep an eye on, not a reason to avoid trying.
>

I'm not parsing your reply properly -- avoid trying what? A common
EXPORT macro that is set as appropriate by each port?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 2:57 PM, Dirk Pranke  wrote:

> On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov  wrote:
> >
> > 31.01.2013, в 14:45, Dirk Pranke  написал(а):
> >
>  One thing to keep an eye on with WEBCORE_EXPORT is that it can
> increase
>  the number of exports for each port, because it would export symbols
> that
>  are only needed for other ports.
> >>>
> >>
> >> I'm not sure I understand the concern here. Is the idea that some
> >> ports might build WebCore as a DLL (and need exports) and others
> >> wouldn't? Or the idea that the API that is needed to be exported might
> >> vary from port to port in such a way that too many symbols for WebCore
> >> might be exported on some ports?
> >
> > The latter.
> >
> > I suspect that it's somewhat less of an issue for JavaScriptCore,
> because its exports are mostly used from cross-platform code.
> >
>
> I see. Some concrete examples would be helpful here (to me, at least).
> What components and ports are we talking about, and what sorts of
> symbols?
>

FWIW, there are quite few symbols exported from EditorMac.mm although of
them are if-def PLATFORM(MAC)'ed in .h anyway.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Alexey Proskuryakov]

31.01.2013, в 14:57, Dirk Pranke  написал(а):

> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
> the number of exports for each port, because it would export symbols that
> are only needed for other ports.
 
>>> 
>>> I'm not sure I understand the concern here. Is the idea that some
>>> ports might build WebCore as a DLL (and need exports) and others
>>> wouldn't? Or the idea that the API that is needed to be exported might
>>> vary from port to port in such a way that too many symbols for WebCore
>>> might be exported on some ports?
>> 
>> The latter.
>> 
>> I suspect that it's somewhat less of an issue for JavaScriptCore, because 
>> its exports are mostly used from cross-platform code.
>> 
> 
> I see. Some concrete examples would be helpful here (to me, at least).
> What components and ports are we talking about, and what sorts of
> symbols?

I don't have concrete examples, and I don't know how big an effect on 
performance increasing the number of exports would have. It's something to keep 
an eye on, not a reason to avoid trying.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Dirk Pranke]

On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov  wrote:
>
> 31.01.2013, в 14:45, Dirk Pranke  написал(а):
>
 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.
>>>
>>
>> I'm not sure I understand the concern here. Is the idea that some
>> ports might build WebCore as a DLL (and need exports) and others
>> wouldn't? Or the idea that the API that is needed to be exported might
>> vary from port to port in such a way that too many symbols for WebCore
>> might be exported on some ports?
>
> The latter.
>
> I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
> exports are mostly used from cross-platform code.
>

I see. Some concrete examples would be helpful here (to me, at least).
What components and ports are we talking about, and what sorts of
symbols?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Alexey Proskuryakov]

31.01.2013, в 14:45, Dirk Pranke  написал(а):

>>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>>> the number of exports for each port, because it would export symbols that
>>> are only needed for other ports.
>> 
> 
> I'm not sure I understand the concern here. Is the idea that some
> ports might build WebCore as a DLL (and need exports) and others
> wouldn't? Or the idea that the API that is needed to be exported might
> vary from port to port in such a way that too many symbols for WebCore
> might be exported on some ports?

The latter.

I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
exports are mostly used from cross-platform code.

- WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Dirk Pranke]

On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa  wrote:
> On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov  wrote:
>>
>>
>> 31.01.2013, в 0:17, Ryosuke Niwa  написал(а):
>>
>>> I did it for WTF and JSC with kevino@.
>>> https://bugs.webkit.org/show_bug.cgi?id=72855
>>> I hope I had had time to extend the work to WebCore, which was my
>>> original goal :-/
>>>
>>> I did it through an automation but the tool was so slow and hacky that it
>>> was not capable for large WebCore codebase.
>>>
>>> Seeing that the number of exported symbol is about 2700, manual work with
>>> regular expression will also work
>>> if it is OK to do the work incrementally... and if you are patient enough
>>> :-)
>>
>>
>> 2700 is a lot of symbols to export! Perhaps we can reduce the number of
>> exported symbols? For example, we can move more code from WebKit into
>> WebCore to share more code between ports so that the API surface WebCore has
>> to expose will be smaller and more well defined.
>>
>>
>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>> the number of exports for each port, because it would export symbols that
>> are only needed for other ports.
>

I'm not sure I understand the concern here. Is the idea that some
ports might build WebCore as a DLL (and need exports) and others
wouldn't? Or the idea that the API that is needed to be exported might
vary from port to port in such a way that too many symbols for WebCore
might be exported on some ports?

>
> Can we make the macro starter and specify ports under which a given symbol
> needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)
>

I'm not sure how this helps, but I think that's because of my previous
comment. I could see something like this maybe being needed in my
later scenario (where MAC might need a symbol exported from WebCore
that Qt needed to keep from being exported)?

Is that a hard requirement, or an optimization?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

[Edward O'Connor]

Hi Nico,

You wrote:

> I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
> nobody ever shipped this and nobody intents to.

Sounds good.


Ted
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Ryosuke Niwa]

See
https://bugs.webkit.org/show_bug.cgi?id=61773
https://bugs.webkit.org/show_bug.cgi?id=64149


On Thu, Jan 31, 2013 at 12:36 PM, Nico Weber  wrote:

> This is a lovely discussion to have every now and then :-)
>
> Maybe the file add/move/delete tool that someone wrote could land
> without xcode support for now? Then the pain of moving files is
> reduced to two systems (xcode and everyone else), and that's something
> that's at least tractable.
>
> Nico
>
> On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke 
> wrote:
> > On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer 
> wrote:
> >>
> >> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
> >>
> >>
> >> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer 
> wrote:
> >>
> >> Am 31.01.2013 um 10:37 schrieb
> - R. Niwa
> :
> >>
> >> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
> >> wrote:
> >>>
> >>> Another option is to add a webkit-patch command for modifying the build
> >>> files. That way, the syntax doesn't need to be overly human friendly.
> There
> >>> was also some attempt to write a tool to add files automatically:
> >>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that
> such a
> >>> tool becomes easier if it would only modify one source of truth and
> >>> generates all other artifacts such as Xcode projects from it.
> >>
> >>
> >> I don't want build file's syntax to be so human unfriendly that I need a
> >> tool for it.
> >>
> >> Often times, these syntax problems can be improved dramatically by
> simple
> >> changes. e.g. we had a similar discussion about TestExpectation syntax,
> and
> >> I'm much happier with the new syntax even though the new syntax is
> >> functionally equivalent to the old one, and two syntaxes are very
> similar.
> >>
> >> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
> >>>
> >>> I’ve experimented with this in the past and you’re right that it
> shouldn’t
> >>> be particularly difficult to do. However, I suspect that the task
> would be
> >>> similar in scope to defining an improved syntax for gyp. And if the
> syntax
> >>> is the primary sticking point with gyp then it’d seem preferable to
> tackle
> >>> initially.
> >>
> >>
> >> Yeah. In fact, we can just come up with whatever syntax we like and
> convert
> >> it to the existing gyp format if the syntax was the biggest issue.
> >>
> >>
> >> Do we want to define the whole build system (including information how
> to
> >> invoke the generators) with the new system, or is a "simple" list for
> the
> >> input files sufficient? IMHO adding a new generator build step happens
> very
> >> rarely. So maybe we can spit the "input file list" (mainly *.cpp and
> *.idl)
> >> into new files.
> >> Then GYP and CMake can read them and generate the build system out of
> them
> >> directly (like they to already today) instead of listing the files in
> the
> >> *.gpyi and *.cmake. This might work for other systems like qmake too.
> >> For XCode we can maybe have a "template XCode project" and generate the
> >> "work XCode project" with a script. This script then only need to fill
> in
> >> the files from the "input file list" into the "template XCode project".
> >> Defining the feature flags can be done like Maciej suggested with
> "Port.h"
> >> files.
> >>
> >>
> >> I think it would be better to adapt an existing meta build system to our
> >> needs than to make one from scratch, unless we find that completely
> >> impractical.
> >>
> >> In particular, gyp and cmake both know how to handle generated sources,
> and
> >> while it may not be super common to make a new type of generated source,
> >> it's bad for hackability of the project of doing so is super hard. We
> get a
> >> lot of hackability benefits from using various kinds of generated
> sources,
> >> many first introduced in the days when we had a lot fewer build
> systems. So
> >> in my mind, they are already ahead of a hypothetical "simple" system.
> >>
> >>
> >> Do you want to kick the requirements of the smaller ports from trunk or
> do
> >> you think that e.g. a qmake generate for GYP makes sense?
> >> AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build
> system,
> >> where CMake/GYP is not an option.
> >>
> >
> > It could certainly make sense for us to add Autotools and Qmake
> > generators to GYP; I'm less certain if a CMake generator makes much
> > sense, but I haven't thought about it as much. I'm not super familiar
> > with any of these three tools, so I could be dead wrong.
> >
> >> I completely agree that creating a new meta meta build system isn't a
> good
> >> idea, but sharing the common parts (which reduce the daily productivity)
> >> might be a step in the right direction. Using simple text files which
> >> contain the list of files (like the gpyi files already do today) isn't
> a new
> >> build system. It only offers the existing meta build systems (CMake,
> GYP,
> >> autotools, qmake) to use a common base.
> >>
> >> The remaining build systems can be ported to one of these systems o

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Nico Weber]

This is a lovely discussion to have every now and then :-)

Maybe the file add/move/delete tool that someone wrote could land
without xcode support for now? Then the pain of moving files is
reduced to two systems (xcode and everyone else), and that's something
that's at least tractable.

Nico

On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke  wrote:
> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer  wrote:
>>
>> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>>
>>
>> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:
>>
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>>
>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
>> wrote:
>>>
>>> Another option is to add a webkit-patch command for modifying the build
>>> files. That way, the syntax doesn't need to be overly human friendly. There
>>> was also some attempt to write a tool to add files automatically:
>>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
>>> tool becomes easier if it would only modify one source of truth and
>>> generates all other artifacts such as Xcode projects from it.
>>
>>
>> I don't want build file's syntax to be so human unfriendly that I need a
>> tool for it.
>>
>> Often times, these syntax problems can be improved dramatically by simple
>> changes. e.g. we had a similar discussion about TestExpectation syntax, and
>> I'm much happier with the new syntax even though the new syntax is
>> functionally equivalent to the old one, and two syntaxes are very similar.
>>
>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>>>
>>> I’ve experimented with this in the past and you’re right that it shouldn’t
>>> be particularly difficult to do. However, I suspect that the task would be
>>> similar in scope to defining an improved syntax for gyp. And if the syntax
>>> is the primary sticking point with gyp then it’d seem preferable to tackle
>>> initially.
>>
>>
>> Yeah. In fact, we can just come up with whatever syntax we like and convert
>> it to the existing gyp format if the syntax was the biggest issue.
>>
>>
>> Do we want to define the whole build system (including information how to
>> invoke the generators) with the new system, or is a "simple" list for the
>> input files sufficient? IMHO adding a new generator build step happens very
>> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl)
>> into new files.
>> Then GYP and CMake can read them and generate the build system out of them
>> directly (like they to already today) instead of listing the files in the
>> *.gpyi and *.cmake. This might work for other systems like qmake too.
>> For XCode we can maybe have a "template XCode project" and generate the
>> "work XCode project" with a script. This script then only need to fill in
>> the files from the "input file list" into the "template XCode project".
>> Defining the feature flags can be done like Maciej suggested with "Port.h"
>> files.
>>
>>
>> I think it would be better to adapt an existing meta build system to our
>> needs than to make one from scratch, unless we find that completely
>> impractical.
>>
>> In particular, gyp and cmake both know how to handle generated sources, and
>> while it may not be super common to make a new type of generated source,
>> it's bad for hackability of the project of doing so is super hard. We get a
>> lot of hackability benefits from using various kinds of generated sources,
>> many first introduced in the days when we had a lot fewer build systems. So
>> in my mind, they are already ahead of a hypothetical "simple" system.
>>
>>
>> Do you want to kick the requirements of the smaller ports from trunk or do
>> you think that e.g. a qmake generate for GYP makes sense?
>> AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
>> where CMake/GYP is not an option.
>>
>
> It could certainly make sense for us to add Autotools and Qmake
> generators to GYP; I'm less certain if a CMake generator makes much
> sense, but I haven't thought about it as much. I'm not super familiar
> with any of these three tools, so I could be dead wrong.
>
>> I completely agree that creating a new meta meta build system isn't a good
>> idea, but sharing the common parts (which reduce the daily productivity)
>> might be a step in the right direction. Using simple text files which
>> contain the list of files (like the gpyi files already do today) isn't a new
>> build system. It only offers the existing meta build systems (CMake, GYP,
>> autotools, qmake) to use a common base.
>>
>> The remaining build systems can be ported to one of these systems or be
>> adopted to use this file lists too.
>>
>> -- Patrick
>
> I suspect that we would quickly find that we would want some sort of
> support for conditionals and/or file inclusion in our "simple text
> files", at which point you basically get a meta-meta-build system :).
> I don't actually think such a thing is that bad of an idea, but it's
> all in the details.
>
> I would like to find a solution w

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke  wrote:

> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer 
> wrote:
> >
> > Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
> >
> >
> > On Jan 31, 2013, at 1:56 AM, Patrick Gansterer 
> wrote:
> >
> > Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
> >
> > On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
> > wrote:
> >>
> >> Another option is to add a webkit-patch command for modifying the build
> >> files. That way, the syntax doesn't need to be overly human friendly.
> There
> >> was also some attempt to write a tool to add files automatically:
> >> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that
> such a
> >> tool becomes easier if it would only modify one source of truth and
> >> generates all other artifacts such as Xcode projects from it.
> >
> >
> > I don't want build file's syntax to be so human unfriendly that I need a
> > tool for it.
> >
> > Often times, these syntax problems can be improved dramatically by simple
> > changes. e.g. we had a similar discussion about TestExpectation syntax,
> and
> > I'm much happier with the new syntax even though the new syntax is
> > functionally equivalent to the old one, and two syntaxes are very
> similar.
> >
> > On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
> >>
> >> I’ve experimented with this in the past and you’re right that it
> shouldn’t
> >> be particularly difficult to do. However, I suspect that the task would
> be
> >> similar in scope to defining an improved syntax for gyp. And if the
> syntax
> >> is the primary sticking point with gyp then it’d seem preferable to
> tackle
> >> initially.
> >
> >
> > Yeah. In fact, we can just come up with whatever syntax we like and
> convert
> > it to the existing gyp format if the syntax was the biggest issue.
> >
> >
> > Do we want to define the whole build system (including information how to
> > invoke the generators) with the new system, or is a "simple" list for the
> > input files sufficient? IMHO adding a new generator build step happens
> very
> > rarely. So maybe we can spit the "input file list" (mainly *.cpp and
> *.idl)
> > into new files.
> > Then GYP and CMake can read them and generate the build system out of
> them
> > directly (like they to already today) instead of listing the files in the
> > *.gpyi and *.cmake. This might work for other systems like qmake too.
> > For XCode we can maybe have a "template XCode project" and generate the
> > "work XCode project" with a script. This script then only need to fill in
> > the files from the "input file list" into the "template XCode project".
> > Defining the feature flags can be done like Maciej suggested with
> "Port.h"
> > files.
> >
> >
> > I think it would be better to adapt an existing meta build system to our
> > needs than to make one from scratch, unless we find that completely
> > impractical.
> >
> > In particular, gyp and cmake both know how to handle generated sources,
> and
> > while it may not be super common to make a new type of generated source,
> > it's bad for hackability of the project of doing so is super hard. We
> get a
> > lot of hackability benefits from using various kinds of generated
> sources,
> > many first introduced in the days when we had a lot fewer build systems.
> So
> > in my mind, they are already ahead of a hypothetical "simple" system.
> >
> >
> > Do you want to kick the requirements of the smaller ports from trunk or
> do
> > you think that e.g. a qmake generate for GYP makes sense?
> > AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
> > where CMake/GYP is not an option.
> >
>
> It could certainly make sense for us to add Autotools and Qmake
> generators to GYP; I'm less certain if a CMake generator makes much
> sense, but I haven't thought about it as much. I'm not super familiar
> with any of these three tools, so I could be dead wrong.
>

I think making Autotools and Qmake use GYP will be a huge win even if we
couldn't make Xcodeproj and CMake use GYP at the end. Having GYP + CMake +
Xcodeproj is much better than having Autotools and Qmake on top of that.

I don't think we need to necessarily unify all build systems. Reducing the
number of build systems is a worthwhile goal on its own merit.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Dirk Pranke]

On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer  wrote:
>
> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>
>
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:
>
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
> wrote:
>>
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be overly human friendly. There
>> was also some attempt to write a tool to add files automatically:
>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
>> tool becomes easier if it would only modify one source of truth and
>> generates all other artifacts such as Xcode projects from it.
>
>
> I don't want build file's syntax to be so human unfriendly that I need a
> tool for it.
>
> Often times, these syntax problems can be improved dramatically by simple
> changes. e.g. we had a similar discussion about TestExpectation syntax, and
> I'm much happier with the new syntax even though the new syntax is
> functionally equivalent to the old one, and two syntaxes are very similar.
>
> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>>
>> I’ve experimented with this in the past and you’re right that it shouldn’t
>> be particularly difficult to do. However, I suspect that the task would be
>> similar in scope to defining an improved syntax for gyp. And if the syntax
>> is the primary sticking point with gyp then it’d seem preferable to tackle
>> initially.
>
>
> Yeah. In fact, we can just come up with whatever syntax we like and convert
> it to the existing gyp format if the syntax was the biggest issue.
>
>
> Do we want to define the whole build system (including information how to
> invoke the generators) with the new system, or is a "simple" list for the
> input files sufficient? IMHO adding a new generator build step happens very
> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl)
> into new files.
> Then GYP and CMake can read them and generate the build system out of them
> directly (like they to already today) instead of listing the files in the
> *.gpyi and *.cmake. This might work for other systems like qmake too.
> For XCode we can maybe have a "template XCode project" and generate the
> "work XCode project" with a script. This script then only need to fill in
> the files from the "input file list" into the "template XCode project".
> Defining the feature flags can be done like Maciej suggested with "Port.h"
> files.
>
>
> I think it would be better to adapt an existing meta build system to our
> needs than to make one from scratch, unless we find that completely
> impractical.
>
> In particular, gyp and cmake both know how to handle generated sources, and
> while it may not be super common to make a new type of generated source,
> it's bad for hackability of the project of doing so is super hard. We get a
> lot of hackability benefits from using various kinds of generated sources,
> many first introduced in the days when we had a lot fewer build systems. So
> in my mind, they are already ahead of a hypothetical "simple" system.
>
>
> Do you want to kick the requirements of the smaller ports from trunk or do
> you think that e.g. a qmake generate for GYP makes sense?
> AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
> where CMake/GYP is not an option.
>

It could certainly make sense for us to add Autotools and Qmake
generators to GYP; I'm less certain if a CMake generator makes much
sense, but I haven't thought about it as much. I'm not super familiar
with any of these three tools, so I could be dead wrong.

> I completely agree that creating a new meta meta build system isn't a good
> idea, but sharing the common parts (which reduce the daily productivity)
> might be a step in the right direction. Using simple text files which
> contain the list of files (like the gpyi files already do today) isn't a new
> build system. It only offers the existing meta build systems (CMake, GYP,
> autotools, qmake) to use a common base.
>
> The remaining build systems can be ported to one of these systems or be
> adopted to use this file lists too.
>
> -- Patrick

I suspect that we would quickly find that we would want some sort of
support for conditionals and/or file inclusion in our "simple text
files", at which point you basically get a meta-meta-build system :).
I don't actually think such a thing is that bad of an idea, but it's
all in the details.

I would like to find a solution where all of the ports were able to
retain integration with their "native" build environments one way or
another.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Hugo Parente Lima]

On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer wrote:
> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
> > On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:
> >> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
> >>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
> >>> wrote: Another option is to add a webkit-patch command for modifying
> >>> the build files. That way, the syntax doesn't need to be overly human
> >>> friendly. There was also some attempt to write a tool to add files
> >>> automatically: https://bugs.webkit.org/show_bug.cgi?ida772  I would
> >>> expect that such a tool becomes easier if it would only modify one
> >>> source of truth and generates all other artifacts such as Xcode
> >>> projects from it.
> >>>
> >>> I don't want build file's syntax to be so human unfriendly that I need a
> >>> tool
for it.
> >>>
> >>> Often times, these syntax problems can be improved dramatically by
> >>> simple changes. e.g. we had a similar discussion about TestExpectation
> >>> syntax, and I'm much happier with the new syntax even though the new
> >>> syntax is functionally equivalent to the old one, and two syntaxes are
> >>> very similar.
> >>>
> >>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
> >>> I’ve experimented with this in the past and you’re right that it
> >>> shouldn’t be particularly difficult to do. However, I suspect that the
> >>> task would be similar in scope to defining an improved syntax for gyp.
> >>> And if the syntax is the primary sticking point with gyp then it’d seem
> >>> preferable to tackle initially.
> >>>
> >>> Yeah. In fact, we can just come up with whatever syntax we like and
> >>> convert it to the existing gyp format if the syntax was the biggest
> >>> issue.>>
> >> Do we want to define the whole build system (including inform
tion how to
> >> invoke the generators) with the new system, or is a "simple" list for
> >> the input files sufficient? IMHO adding a new generator build step
> >> happens very rarely. So maybe we can spit the "input file list" (mainly
> >> *.cpp and *.idl) into new files. Then GYP and CMake can read them and
> >> generate the build system out of them directly (like they to already
> >> today) instead of listing the files in the *.gpyi and *.cmake. This
> >> might work for other systems like qmake too. For XCode we can maybe have
> >> a "template XCode project" and generate the "work XCode project" with a
> >> script. This script then only need to fill in the files from the "input
> >> file list" into the "template XCode project". Defining the feature flags
> >> can be done like Maciej suggested with "Port.h" files.>
> > I think it would be better to adapt an existing meta build system to our
> > needs than to make one from scratch, unless we find that completely
> > impractical.
> >
> > I
 particular, gyp and cmake both know how to handle generated sources,
> > and while it may not be super common to make a new type of generated
> > source, it's bad for hackability of the project of doing so is super
> > hard. We get a lot of hackability benefits from using various kinds of
> > generated sources, many first introduced in the days when we had a lot
> > fewer build systems. So in my mind, they are already ahead of a
> > hypothetical "simple" system.
> Do you want to kick the requirements of the smaller ports from trunk or do
> you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g.
> QtWebKit is shipped with Qt, which uses qmake as build system, where
> CMake/GYP is not an option.
>
> I completely agree that creating a new meta meta build system isn't a good
> idea, but sharing the common parts (which reduce the daily productivity)
> might be a step in the right direction. Using simple text files which
> contain the list of files (like the gpyi files already do tod
y) isn't a
> new build system. It only offers the existing meta build systems (CMake,
> GYP, autotools, qmake) to use a common base.

I agree, common build system on WebKit is an utopia, create a new meta build
system isn't a good idea, so the only plausible option is to unify way we
add/remove/modify files from the build. Create a script to do this on all build
system is yet another utopia, so again, the only option is to have plain text
files.

Going a bit further on this idea, would be nice to also have conditionals on
these plain text files to cover the use case of e.g. "add foo.cpp to the build
when ENABLE_FOO or WTF_USE_FOO is on" would be even better, a script would be
called passing all ENABLE, USE, HAVE, etc.. flags and returning a list of files,
the only question is if all current build system would support such "dynamic"
source file list, CMake does :-)

> The remaining build systems can be ported to one of these systems or be
> adopted to use this file lists too.
>

> -- Patrick

pgpVpcWAo2RvL.pgp
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Dirk Pranke]

On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer  wrote:
>
> Am 31.01.2013 um 21:07 schrieb Dirk Pranke:
>
>> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
>>  wrote:
>>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
> On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
>> Thanks for sharing this.
>>
>> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>>
>> I wish we only had one build system (it were easy to add/remove/move
>> files).
>>
>> I believe changes like http://trac.webkit.org/changeset/74849 are an
>> unhealthy sign for the project.  Adam is not the only person who has
>> chosen
>> to empty files instead of removing them.  The pain of updating 8 build
>> system is so great, we jump through hoops to avoid it.  Which means it
>> took
>> us months to move JavaScriptCore/wtf to WTF, and will take us years to
>> kill
>> WebCore/platform.
>>
>>
>> +1
>>
>> This is a hard problem.  It is a problem worth solving.
>>
>> Do you have more thoughts on this, particularly since you know quite well
>> how both Xcode and gyp work?
>>
>> I suspect this is one of those things that it would be hard to achieve
>> consensus on since there are so many stakeholders.  But it may be
>> fruitful
>> to have a "what if" discussion about what this might look like.
>
> I think we can solve this problem if we agree that we want to. I think
> we haven't in the past mostly because we couldn't reach a consensus
> that it was worth solving enough to really try.
>
> I would love to see this fixed and would be glad to work on it. I
> think we should at least pursue this far enough to fully understand
> what our options are and what the costs and tradeoffs might be; does
> anyone disagree, and is anyone else willing to help pitch in?
>
> I think there are several possible ways we could solve this. One would
> be to switch to a common meta-build system. My understanding is that
> Apple's internal production build processes impose certain constraints
> here that I don't fully understand, but I know we've discussed the
> possibility of checking in generated project files as a workaround.
> Maybe there are other options as well to those constraints? I would
> love to discuss this further w/ someone from Apple ...

 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.

 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
> (Also, just to get this out of the way, I don't think gyp needs to be
> the solution).
>
> Another alternative would be to write a script that did support at
> least the common use cases (add/move/delete files). There have been
> attempts in the past, but they have foundered on at least some
> perceived skepticism over how well this would work w/ XCode. That
> said, I don't think we've really pushed this to see. At some point
> this script might turn into a meta-meta-build system, which might be
> silly but also be the shortest path to the finish line.
>
> I suggest if there is interest in this we can start a new thread to
> discuss further ...

 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.

 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.

 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.

 I'd also like to add that I think a key related issue to common build 
 system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.
>>>
>>> I have a patch trying to solve this issue for CMake based ports[1], the 
>>> patch
>>> still on going, but even a change affecting just 2-3 ports using the same 
>>> build
>>> system is a bit hard to get a consensus, so you can imagine how hard will be
>>> to get a consensus over all WebKit ports.
>>>
>>> [1] https://bugs.webkit.org/show_bug.cgi?id=103162
>>>
>>
>> This is slightly off-topic, but I had thought that no one was actually
>> using CMake; maybe I was mis

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Patrick Gansterer]

Am 31.01.2013 um 21:07 schrieb Dirk Pranke:

> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
>  wrote:
>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
> Thanks for sharing this.
> 
> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
> 
> I wish we only had one build system (it were easy to add/remove/move
> files).
> 
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has
> chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it
> took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to
> kill
> WebCore/platform.
> 
> 
> +1
> 
> This is a hard problem.  It is a problem worth solving.
> 
> Do you have more thoughts on this, particularly since you know quite well
> how both Xcode and gyp work?
> 
> I suspect this is one of those things that it would be hard to achieve
> consensus on since there are so many stakeholders.  But it may be
> fruitful
> to have a "what if" discussion about what this might look like.
 
 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.
 
 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?
 
 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...
>>> 
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>>> checked in to source control. (b) The generated project invokes only tools
>>> that are part of the default Mac OS X install.
>>> 
>>> It may not be completely impossible to violate these requirements but it
>>> will require a lot of bureaucracy.
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).
 
 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.
 
 I suggest if there is interest in this we can start a new thread to
 discuss further ...
>>> 
>>> My preference would be to use a common meta-build system with a comfortably
>>> human-readable and human-editable syntax, and checked in generated project
>>> files for those ports that need them.
>>> 
>>> I think a key to making this work is to get Chromium and the Apple Mac port
>>> onto a common build system, which will probably require both Google and
>>> Apple ponying up at least one person to work on this project for a
>>> reasonable period of time.
>>> 
>>> I think the plausible meta-build-systems to use would be CMake and Gyp, but
>>> in both cases it may be necessary to modify them to work well for everyone.
>>> 
>>> I'd also like to add that I think a key related issue to common build system
>>> is common feature configuration. The many different ways ports control
>>> their feature flags is super confusing. I've long wanted to implement
>>> common configuration management, but have not had time.
>> 
>> I have a patch trying to solve this issue for CMake based ports[1], the patch
>> still on going, but even a change affecting just 2-3 ports using the same 
>> build
>> system is a bit hard to get a consensus, so you can imagine how hard will be
>> to get a consensus over all WebKit ports.
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=103162
>> 
> 
> This is slightly off-topic, but I had thought that no one was actually
> using CMake; maybe I was mistaken and just none of the ports that
> build on webkit.org are? It looks like Blackberry and maybe a WinCE
> port uses CMake? Anyone else?

EFL uses CMa

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Dirk Pranke]

On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
 wrote:
> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
>> >> Thanks for sharing this.
>> >>
>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>> >>
>> >> I wish we only had one build system (it were easy to add/remove/move
>> >> files).
>> >>
>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>> >> unhealthy sign for the project.  Adam is not the only person who has
>> >> chosen
>> >> to empty files instead of removing them.  The pain of updating 8 build
>> >> system is so great, we jump through hoops to avoid it.  Which means it
>> >> took
>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years to
>> >> kill
>> >> WebCore/platform.
>> >>
>> >>
>> >> +1
>> >>
>> >> This is a hard problem.  It is a problem worth solving.
>> >>
>> >> Do you have more thoughts on this, particularly since you know quite well
>> >> how both Xcode and gyp work?
>> >>
>> >> I suspect this is one of those things that it would be hard to achieve
>> >> consensus on since there are so many stakeholders.  But it may be
>> >> fruitful
>> >> to have a "what if" discussion about what this might look like.
>> >
>> > I think we can solve this problem if we agree that we want to. I think
>> > we haven't in the past mostly because we couldn't reach a consensus
>> > that it was worth solving enough to really try.
>> >
>> > I would love to see this fixed and would be glad to work on it. I
>> > think we should at least pursue this far enough to fully understand
>> > what our options are and what the costs and tradeoffs might be; does
>> > anyone disagree, and is anyone else willing to help pitch in?
>> >
>> > I think there are several possible ways we could solve this. One would
>> > be to switch to a common meta-build system. My understanding is that
>> > Apple's internal production build processes impose certain constraints
>> > here that I don't fully understand, but I know we've discussed the
>> > possibility of checking in generated project files as a workaround.
>> > Maybe there are other options as well to those constraints? I would
>> > love to discuss this further w/ someone from Apple ...
>>
>> It's far simplest for us if:
>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>> checked in to source control. (b) The generated project invokes only tools
>> that are part of the default Mac OS X install.
>>
>> It may not be completely impossible to violate these requirements but it
>> will require a lot of bureaucracy.
>> > (Also, just to get this out of the way, I don't think gyp needs to be
>> > the solution).
>> >
>> > Another alternative would be to write a script that did support at
>> > least the common use cases (add/move/delete files). There have been
>> > attempts in the past, but they have foundered on at least some
>> > perceived skepticism over how well this would work w/ XCode. That
>> > said, I don't think we've really pushed this to see. At some point
>> > this script might turn into a meta-meta-build system, which might be
>> > silly but also be the shortest path to the finish line.
>> >
>> > I suggest if there is interest in this we can start a new thread to
>> > discuss further ...
>>
>> My preference would be to use a common meta-build system with a comfortably
>> human-readable and human-editable syntax, and checked in generated project
>> files for those ports that need them.
>>
>> I think a key to making this work is to get Chromium and the Apple Mac port
>> onto a common build system, which will probably require both Google and
>> Apple ponying up at least one person to work on this project for a
>> reasonable period of time.
>>
>> I think the plausible meta-build-systems to use would be CMake and Gyp, but
>> in both cases it may be necessary to modify them to work well for everyone.
>>
>> I'd also like to add that I think a key related issue to common build system
>> is common feature configuration. The many different ways ports control
>> their feature flags is super confusing. I've long wanted to implement
>> common configuration management, but have not had time.
>
> I have a patch trying to solve this issue for CMake based ports[1], the patch
> still on going, but even a change affecting just 2-3 ports using the same 
> build
> system is a bit hard to get a consensus, so you can imagine how hard will be
> to get a consensus over all WebKit ports.
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=103162
>

This is slightly off-topic, but I had thought that no one was actually
using CMake; maybe I was mistaken and just none of the ports that
build on webkit.org are? It looks like Blackberry and maybe a WinCE
port uses CMake? Anyone else?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.o

Re: [webkit-dev] Media Server Development

[John Yani]

Hi Kiran,

I'm afraid, this is not the right place to ask questions like that. Try
asking webkit-help.

On 31 January 2013 19:34, Kiran K  wrote:

> HI All,
>
> I am working on QtWebKit  on Media Server development. Basic Idea is to
> run Gstreamer in seperate process which acts like a Media server. The
> calls  from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media
> Server via DBUS. Media Server implements the methods in
> MediaPlayerPrivateGStreamer class. I am basically doing this to have
> control over the resources like maximum playback instances, hw codec
> control etc. I am able to do achieve playback to some extent. I am facing
> some problems  (race conditions) especially when deleting playback
> instance. From the logs i concluded that when duration() function is made
> and is waiting for response from server, ~MediaPlayerPrivateGStreamer
> destructor is getting called. (some times vice versa too). I am suspecting
> that the MediaPlayer object is being shared between two threads (or across
> timers). Can anybody give me some pointers about HTMLMediaElement  and the
> timers involved? Any help is appreciated.
>
> Thanks,
> Arun
>
>
> ___
> 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

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Hugo Parente Lima]

On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
> >> Thanks for sharing this.
> >> 
> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
> >> 
> >> I wish we only had one build system (it were easy to add/remove/move
> >> files).
> >> 
> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
> >> unhealthy sign for the project.  Adam is not the only person who has
> >> chosen
> >> to empty files instead of removing them.  The pain of updating 8 build
> >> system is so great, we jump through hoops to avoid it.  Which means it
> >> took
> >> us months to move JavaScriptCore/wtf to WTF, and will take us years to
> >> kill
> >> WebCore/platform.
> >> 
> >> 
> >> +1
> >> 
> >> This is a hard problem.  It is a problem worth solving.
> >> 
> >> Do you have more thoughts on this, particularly since you know quite well
> >> how both Xcode and gyp work?
> >> 
> >> I suspect this is one of those things that it would be hard to achieve
> >> consensus on since there are so many stakeholders.  But it may be
> >> fruitful
> >> to have a "what if" discussion about what this might look like.
> > 
> > I think we can solve this problem if we agree that we want to. I think
> > we haven't in the past mostly because we couldn't reach a consensus
> > that it was worth solving enough to really try.
> > 
> > I would love to see this fixed and would be glad to work on it. I
> > think we should at least pursue this far enough to fully understand
> > what our options are and what the costs and tradeoffs might be; does
> > anyone disagree, and is anyone else willing to help pitch in?
> > 
> > I think there are several possible ways we could solve this. One would
> > be to switch to a common meta-build system. My understanding is that
> > Apple's internal production build processes impose certain constraints
> > here that I don't fully understand, but I know we've discussed the
> > possibility of checking in generated project files as a workaround.
> > Maybe there are other options as well to those constraints? I would
> > love to discuss this further w/ someone from Apple ...
> 
> It's far simplest for us if:
> (a) There is an Xcode project (or a Makefile) that builds the Mac port
> checked in to source control. (b) The generated project invokes only tools
> that are part of the default Mac OS X install.
> 
> It may not be completely impossible to violate these requirements but it
> will require a lot of bureaucracy.
> > (Also, just to get this out of the way, I don't think gyp needs to be
> > the solution).
> > 
> > Another alternative would be to write a script that did support at
> > least the common use cases (add/move/delete files). There have been
> > attempts in the past, but they have foundered on at least some
> > perceived skepticism over how well this would work w/ XCode. That
> > said, I don't think we've really pushed this to see. At some point
> > this script might turn into a meta-meta-build system, which might be
> > silly but also be the shortest path to the finish line.
> > 
> > I suggest if there is interest in this we can start a new thread to
> > discuss further ...
> 
> My preference would be to use a common meta-build system with a comfortably
> human-readable and human-editable syntax, and checked in generated project
> files for those ports that need them.
> 
> I think a key to making this work is to get Chromium and the Apple Mac port
> onto a common build system, which will probably require both Google and
> Apple ponying up at least one person to work on this project for a
> reasonable period of time.
> 
> I think the plausible meta-build-systems to use would be CMake and Gyp, but
> in both cases it may be necessary to modify them to work well for everyone.
> 
> I'd also like to add that I think a key related issue to common build system
> is common feature configuration. The many different ways ports control
> their feature flags is super confusing. I've long wanted to implement
> common configuration management, but have not had time.

I have a patch trying to solve this issue for CMake based ports[1], the patch 
still on going, but even a change affecting just 2-3 ports using the same build 
system is a bit hard to get a consensus, so you can imagine how hard will be 
to get a consensus over all WebKit ports.
 
[1] https://bugs.webkit.org/show_bug.cgi?id=103162

> Cheers,
> Maciej
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Media Server Development

[Arunprasad RajKumar]

Basically WebKit runs in the event thread(main thread) of the porting(qt,gtk). 
WebKit node data structures will be created and destroyed only from the 
mainthread. Also WebKit's timer scheduled from the main thread. Are u running 
multiple instance of webview from multiple  threads? If so it shouldn't be done 
like tat. You can check the thread id of duration and destrutor's caller if u r 
not sure.

Sent from my Xperia™ smartphone 

Kiran K  wrote:

>HI All,
>
>I am working on QtWebKit  on Media Server development. Basic Idea is to run
>Gstreamer in seperate process which acts like a Media server. The calls
>from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media Server
>via DBUS. Media Server implements the methods in
>MediaPlayerPrivateGStreamer class. I am basically doing this to have
>control over the resources like maximum playback instances, hw codec
>control etc. I am able to do achieve playback to some extent. I am facing
>some problems  (race conditions) especially when deleting playback
>instance. From the logs i concluded that when duration() function is made
>and is waiting for response from server, ~MediaPlayerPrivateGStreamer
>destructor is getting called. (some times vice versa too). I am suspecting
>that the MediaPlayer object is being shared between two threads (or across
>timers). Can anybody give me some pointers about HTMLMediaElement  and the
>timers involved? Any help is appreciated.
>
>Thanks,
>Arun
>
>___
>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

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Alexey Proskuryakov]

30.01.2013, в 17:14, Dirk Pranke  написал(а):

> CMake was originally considered a non-starter for chromium since the
> XCode and VS projects it produced didn't look or feel like native
> projects.

I think that this is the key consideration here. Whatever the pains of 
modifying multiple build systems files are, reading and - to a lesser extent - 
modifying actual code is the most important activity to optimize for.

It's not so helpful to have an easy way to add code if the only reason you are 
adding it is that you could not easily navigate the code base to find an 
already existing solution.

To me personally, this means that Xcode project files need to be fully usable.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov  wrote:

>
> 31.01.2013, в 0:17, Ryosuke Niwa  написал(а):
>
>  I did it for WTF and JSC with kevino@.
>> https://bugs.webkit.org/show_bug.cgi?id=72855
>> I hope I had had time to extend the work to WebCore, which was my
>> original goal :-/
>>
>> I did it through an automation but the tool was so slow and hacky that it
>> was not capable for large WebCore codebase.
>>
>> Seeing that the number of exported symbol is about 2700, manual work with
>> regular expression will also work
>> if it is OK to do the work incrementally... and if you are patient enough
>> :-)
>>
>
> 2700 is a lot of symbols to export! Perhaps we can reduce the number of
> exported symbols? For example, we can move more code from WebKit into
> WebCore to share more code between ports so that the API surface WebCore
> has to expose will be smaller and more well defined.
>
>
> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
> the number of exports for each port, because it would export symbols that
> are only needed for other ports.
>

Can we make the macro starter and specify ports under which a given symbol
needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Media Server Development

[Kiran K]

HI All,

I am working on QtWebKit  on Media Server development. Basic Idea is to run
Gstreamer in seperate process which acts like a Media server. The calls
from WebKit in MediaPlayerPrivateGStreamer.cpp are routed to Media Server
via DBUS. Media Server implements the methods in
MediaPlayerPrivateGStreamer class. I am basically doing this to have
control over the resources like maximum playback instances, hw codec
control etc. I am able to do achieve playback to some extent. I am facing
some problems  (race conditions) especially when deleting playback
instance. From the logs i concluded that when duration() function is made
and is waiting for response from server, ~MediaPlayerPrivateGStreamer
destructor is getting called. (some times vice versa too). I am suspecting
that the MediaPlayer object is being shared between two threads (or across
timers). Can anybody give me some pointers about HTMLMediaElement  and the
timers involved? Any help is appreciated.

Thanks,
Arun
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Patrick Gansterer]

Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:

> 
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:
> 
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>> 
>>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger  
>>> wrote:
>>> Another option is to add a webkit-patch command for modifying the build 
>>> files. That way, the syntax doesn't need to be overly human friendly. There 
>>> was also some attempt to write a tool to add files automatically: 
>>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
>>> tool becomes easier if it would only modify one source of truth and 
>>> generates all other artifacts such as Xcode projects from it.
>>> 
>>> I don't want build file's syntax to be so human unfriendly that I need a 
>>> tool for it.
>>> 
>>> Often times, these syntax problems can be improved dramatically by simple 
>>> changes. e.g. we had a similar discussion about TestExpectation syntax, and 
>>> I'm much happier with the new syntax even though the new syntax is 
>>> functionally equivalent to the old one, and two syntaxes are very similar.
>>> 
>>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>>> I’ve experimented with this in the past and you’re right that it shouldn’t 
>>> be particularly difficult to do. However, I suspect that the task would be 
>>> similar in scope to defining an improved syntax for gyp. And if the syntax 
>>> is the primary sticking point with gyp then it’d seem preferable to tackle 
>>> initially.
>>> 
>>> Yeah. In fact, we can just come up with whatever syntax we like and convert 
>>> it to the existing gyp format if the syntax was the biggest issue.
>> 
>> Do we want to define the whole build system (including information how to 
>> invoke the generators) with the new system, or is a "simple" list for the 
>> input files sufficient? IMHO adding a new generator build step happens very 
>> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl) 
>> into new files.
>> Then GYP and CMake can read them and generate the build system out of them 
>> directly (like they to already today) instead of listing the files in the 
>> *.gpyi and *.cmake. This might work for other systems like qmake too.
>> For XCode we can maybe have a "template XCode project" and generate the 
>> "work XCode project" with a script. This script then only need to fill in 
>> the files from the "input file list" into the "template XCode project".
>> Defining the feature flags can be done like Maciej suggested with "Port.h" 
>> files.
> 
> I think it would be better to adapt an existing meta build system to our 
> needs than to make one from scratch, unless we find that completely 
> impractical.
> 
> In particular, gyp and cmake both know how to handle generated sources, and 
> while it may not be super common to make a new type of generated source, it's 
> bad for hackability of the project of doing so is super hard. We get a lot of 
> hackability benefits from using various kinds of generated sources, many 
> first introduced in the days when we had a lot fewer build systems. So in my 
> mind, they are already ahead of a hypothetical "simple" system.


Do you want to kick the requirements of the smaller ports from trunk or do you 
think that e.g. a qmake generate for GYP makes sense?
AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where 
CMake/GYP is not an option.

I completely agree that creating a new meta meta build system isn't a good 
idea, but sharing the common parts (which reduce the daily productivity) might 
be a step in the right direction. Using simple text files which contain the 
list of files (like the gpyi files already do today) isn't a new build system. 
It only offers the existing meta build systems (CMake, GYP, autotools, qmake) 
to use a common base.

The remaining build systems can be ported to one of these systems or be adopted 
to use this file lists too.

-- Patrick___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Maciej Stachowiak]

On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:

> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
> 
>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger  wrote:
>> Another option is to add a webkit-patch command for modifying the build 
>> files. That way, the syntax doesn't need to be overly human friendly. There 
>> was also some attempt to write a tool to add files automatically: 
>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
>> tool becomes easier if it would only modify one source of truth and 
>> generates all other artifacts such as Xcode projects from it.
>> 
>> I don't want build file's syntax to be so human unfriendly that I need a 
>> tool for it.
>> 
>> Often times, these syntax problems can be improved dramatically by simple 
>> changes. e.g. we had a similar discussion about TestExpectation syntax, and 
>> I'm much happier with the new syntax even though the new syntax is 
>> functionally equivalent to the old one, and two syntaxes are very similar.
>> 
>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>> I’ve experimented with this in the past and you’re right that it shouldn’t 
>> be particularly difficult to do. However, I suspect that the task would be 
>> similar in scope to defining an improved syntax for gyp. And if the syntax 
>> is the primary sticking point with gyp then it’d seem preferable to tackle 
>> initially.
>> 
>> Yeah. In fact, we can just come up with whatever syntax we like and convert 
>> it to the existing gyp format if the syntax was the biggest issue.
> 
> Do we want to define the whole build system (including information how to 
> invoke the generators) with the new system, or is a "simple" list for the 
> input files sufficient? IMHO adding a new generator build step happens very 
> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl) 
> into new files.
> Then GYP and CMake can read them and generate the build system out of them 
> directly (like they to already today) instead of listing the files in the 
> *.gpyi and *.cmake. This might work for other systems like qmake too.
> For XCode we can maybe have a "template XCode project" and generate the "work 
> XCode project" with a script. This script then only need to fill in the files 
> from the "input file list" into the "template XCode project".
> Defining the feature flags can be done like Maciej suggested with "Port.h" 
> files.

I think it would be better to adapt an existing meta build system to our needs 
than to make one from scratch, unless we find that completely impractical.

In particular, gyp and cmake both know how to handle generated sources, and 
while it may not be super common to make a new type of generated source, it's 
bad for hackability of the project of doing so is super hard. We get a lot of 
hackability benefits from using various kinds of generated sources, many first 
introduced in the days when we had a lot fewer build systems. So in my mind, 
they are already ahead of a hypothetical "simple" system.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Maciej Stachowiak]

On Jan 31, 2013, at 12:49 AM, Patrick Gansterer  wrote:

> Hi,
> 
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> 
>>> Regarding "(b) The generated project invokes only tools that are part
>>> of the default Mac OS X install": invoking tools that are checked into
>>> the WK repo is also possible, right, since we invoke scripts now? So,
>>> hypothetically, could we check in a copy of the ninja binary and build
>>> with that?
>> 
>> Checking in binaries isn’t an option for us, and isn’t a particularly 
>> scalable approach anyway given the number of platforms that WebKit can build 
>> on. If we require an external tool as a dependency to build WebKit from 
>> source then we’d need to check in the source for the tool and build it prior 
>> to building WebKit proper. This obviously introduces more complexity so it 
>> would be preferable to keep the dependencies to a minimum.
> 
> Maybe you can check in the ninja source and compile it during build. It only 
> requires python (and hopefully installed build tools) to get built.

Depending on how this is done it might be possible, but as I understand it gyp 
can build ok without ninja, so it doesn't seem strictly necessary.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Wishes

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard  wrote:

> On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel  wrote:
> >
> > I wish we didn’t have to worry about platforms we couldn’t test.
> >
> > It can’t be the job of the core maintainers to care about all the
> peripheral
> > ports which contribute very little core code. Our code needs to be
> > structured in such a manner that its easy for the core to march forward,
> > while letting the ports catch up as they need to asynchronously.
>  Platform
> > support code shouldn’t even need to be in webkit.org!  Porting
> webkit.org’s
> > platform abstractions should be trivial, but core developers (which
> probably
> > 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
> > worry about keeping all ports working.
>
> Sure. I'm wondering how you would define a "peripheral" port? Anything
> not Apple or Google?
>
> Many "little" ports are very active every day, sure some of them does
> not contribute as much as they should on common parts but some
> companies behind these are just limited on resources. They are not
> Google or Apple with an army of engineers who have time to take any
> spec of W3C and implements it.
>
> In WebCore the contribution is pain mostly because the buildsystem.
> For the rest if EWS goes red, in many cases it's a real bug, a real
> problem.
>
> Coming from a so called "peripheral" port I find very frustrating and
> demotivating that our contributions are devalorized the way they are
> or our reviews discredited. Many of us contributes important feature
> and improvements to WebCore and sure not as visible as Google or Apple
> in terms of log but still crucial or important.
>
> I believe you and many people are not aware what "little" ports
> contribute because we don't work on high visibility feature such as
> Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
> media queries, viewport interactions, @viewport rule, various work on
> tests infrastructure, WebGL fixes) and I'm talking only of the people
> in my company and I'm probably forgetting some work. The number of
> contributions per day makes hard for me to see what others than Google
> or Apple are doing.
>
> I tend to agree that some are not playing the game but for the ones
> who try their best it's sad to be rejected like that.
>

I don't think Eric's intended to marginalize the importance or the value of
contributions non-Apple/Google ports have been making.

I think he's merely trying to point out that the ratio of the contribution
each port makes to the cost the same port imposes, i.e. contribution/cost,
is positively correlated with the size of a port. Larger the port, it can
contribute more to the core code without imposing proportionally larger
cost. Smaller the port, it needs to spend more time fixing and implementing
its own port-specific code. In some cases, they may not have resources or
expertises to help other contributors trying to make a large refactoring.

While contributors from a smal port may feel as though their work
is marginalized and other ports' contributors ruthlessly break their port,
contributors from a large port often feel that they're being taxed by small
ports; having to maintain other ports without getting much benefit out of
them.

And I suggest we *find a technical solution *to this problem instead of
talking about which philosophy or policy is "right".

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Wishes

[Alexis Menard]

On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel  wrote:
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
> WebCore/platform.
>
>
> I wish I felt like reviewers understood/trusted each other more.
>
> I’ve worked at both Apple and Google.  The WebKit community is full of
> brilliant engineers.  Yet I frequently feel a lack of trust in my (or
> others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
> don’t think it’s that people don’t trust me after nearly 8 years (!?) on
> this project, but rather that we forget, or fail to communicate trust among
> ourselves.  Social problems are perhaps harder to solve for us technical
> types, but I worry that for many of us it’s just become “us” and “them” and
> we’ve stopped trying.
>
>
> I wish it were easy to work on feature branches.
>
> We have no good solution for features.  For one-patch features, you do them
> on your own.  For larger, you maybe use github or most likely you just land
> on trunk behind a #define.  None of these have worked well.  Some of this is
> the limits of SVN, but it should be trivial for someone to work on a new
> feature a long time, w/o endangering trunk or having massive merge pain
> every day.  Other projects can do this.  So should we.  This is both
> impeding progress, and destabilizing trunk.
>
>
> I wish we didn’t have to worry about platforms we couldn’t test.
>
> It can’t be the job of the core maintainers to care about all the peripheral
> ports which contribute very little core code. Our code needs to be
> structured in such a manner that its easy for the core to march forward,
> while letting the ports catch up as they need to asynchronously.  Platform
> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
> platform abstractions should be trivial, but core developers (which probably
> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
> worry about keeping all ports working.

Sure. I'm wondering how you would define a "peripheral" port? Anything
not Apple or Google?

Many "little" ports are very active every day, sure some of them does
not contribute as much as they should on common parts but some
companies behind these are just limited on resources. They are not
Google or Apple with an army of engineers who have time to take any
spec of W3C and implements it.

In WebCore the contribution is pain mostly because the buildsystem.
For the rest if EWS goes red, in many cases it's a real bug, a real
problem.

Coming from a so called "peripheral" port I find very frustrating and
demotivating that our contributions are devalorized the way they are
or our reviews discredited. Many of us contributes important feature
and improvements to WebCore and sure not as visible as Google or Apple
in terms of log but still crucial or important.

I believe you and many people are not aware what "little" ports
contribute because we don't work on high visibility feature such as
Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
media queries, viewport interactions, @viewport rule, various work on
tests infrastructure, WebGL fixes) and I'm talking only of the people
in my company and I'm probably forgetting some work. The number of
contributions per day makes hard for me to see what others than Google
or Apple are doing.

I tend to agree that some are not playing the game but for the ones
who try their best it's sad to be rejected like that.

>
>
> I wish that the tree always built and tested cleanly.
>
> Other (much larger) projects than WebKit accomplish this.  Yet somehow
> Google pays 2 full-time engineers to watch our bots and yet we fail.  I know
> other companies do similar.  Automated rollouts is one solution.
> Branched-based development, or trybots are others.  But at the size and
> scale we’re at now, every minute of a broken tree, is 100x or more minutes
> of potentially lost developer productivity.
>
>
> I wish I felt like I could follow what was going on (and trust WebKit to
> guard the web, instead of depending on Apple or Google).
>
> We’re the leading browser engine, with hundreds of committers, any of whom
> can add an API to 50% of internet browsers with a single commit.  I wish we
> had a public process for feature/web-api review.  I wish I felt like both
> major companies were willing participants in such.  (Google has an internal
> process, but it sees limited use, in part because it’s powerless -- a ‘yes’
> from our process is not a ‘yes’ from WebKit.)  I want to feel like I can
> better observe and participate in the development of our web-ap

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 10:37 AM, Ryosuke Niwa  wrote:

> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:
>
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be overly human friendly. There
>> was also some attempt to write a tool to add files automatically:
>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such
>> a tool becomes easier if it would only modify one source of truth and
>> generates all other artifacts such as Xcode projects from it.
>>
>
> I don't want build file's syntax to be so human unfriendly that I need a
> tool for it.
>
> Often times, these syntax problems can be improved dramatically by simple
> changes. e.g. we had a similar discussion about TestExpectation syntax, and
> I'm much happier with the new syntax even though the new syntax is
> functionally equivalent to the old one, and two syntaxes are very similar.
>

I totally agree. I guess I just failed at finding the right words.

-jochen


>
> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>
>> I’ve experimented with this in the past and you’re right that it
>> shouldn’t be particularly difficult to do. However, I suspect that the task
>> would be similar in scope to defining an improved syntax for gyp. And if
>> the syntax is the primary sticking point with gyp then it’d seem preferable
>> to tackle initially.
>>
>
> Yeah. In fact, we can just come up with whatever syntax we like and
> convert it to the existing gyp format if the syntax was the biggest issue.
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Alexis Menard]

On Thu, Jan 31, 2013 at 6:56 AM, Patrick Gansterer  wrote:
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
> wrote:
>>
>> Another option is to add a webkit-patch command for modifying the build
>> files. That way, the syntax doesn't need to be overly human friendly. There
>> was also some attempt to write a tool to add files automatically:
>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
>> tool becomes easier if it would only modify one source of truth and
>> generates all other artifacts such as Xcode projects from it.
>
>
> I don't want build file's syntax to be so human unfriendly that I need a
> tool for it.
>
> Often times, these syntax problems can be improved dramatically by simple
> changes. e.g. we had a similar discussion about TestExpectation syntax, and
> I'm much happier with the new syntax even though the new syntax is
> functionally equivalent to the old one, and two syntaxes are very similar.
>
> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>>
>> I’ve experimented with this in the past and you’re right that it shouldn’t
>> be particularly difficult to do. However, I suspect that the task would be
>> similar in scope to defining an improved syntax for gyp. And if the syntax
>> is the primary sticking point with gyp then it’d seem preferable to tackle
>> initially.
>
>
> Yeah. In fact, we can just come up with whatever syntax we like and convert
> it to the existing gyp format if the syntax was the biggest issue.
>
>
> Do we want to define the whole build system (including information how to
> invoke the generators) with the new system, or is a "simple" list for the
> input files sufficient? IMHO adding a new generator build step happens very
> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl)
> into new files.
> Then GYP and CMake can read them and generate the build system out of them
> directly (like they to already today) instead of listing the files in the
> *.gpyi and *.cmake. This might work for other systems like qmake too.
> For XCode we can maybe have a "template XCode project" and generate the
> "work XCode project" with a script. This script then only need to fill in
> the files from the "input file list" into the "template XCode project".
> Defining the feature flags can be done like Maciej suggested with "Port.h"
> files.

My 2 cents.

One advantage CMake has over other proposals is that it's already
working for 2 ports (and potentially 4). It is an open source project
so we could potentially contribute to it to add or fix what is needed.
One other good point for CMake is that it's widely used in the
industry and it is backed by a company. When KDE switched over CMake
the guys behind CMake were very very responsive, I believe they will
be too if we plan to switch to CMake. The more famous projects they
have running CMake, the better it is for them. So if we need to
improve the Xcode support then I bet we can count on them. CMake has
also some support in various IDE, and if not then the native solution
is a fallback.

Sure the syntax is maybe not the best but it no worst than Gyp, Xcode,
Makefiles, qmake or some perl script. We already live with all these
syntax and people are also used to edit the CMake related project.

Perfect build system do not exist it's a fact.

On the other hand I don't want to loose the native support like Xcode.
I don't know if many are using it but I find incredibly convenient to
open the Xcode workspace of WebKit, setup the two little things
instructed in the wiki and press cmd+b and it just works, it builds,
it integrate with Xcode (so you get the neat features of pretty output
compiles errors with jumping, ...) and I press cmd+r and it launch
MiniBrowser or something else to debug from within the IDE. This is
what makes the Mac port a very great port to work on.

>
> -- Patrick
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Patrick Gansterer]

Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger  wrote:
> Another option is to add a webkit-patch command for modifying the build 
> files. That way, the syntax doesn't need to be overly human friendly. There 
> was also some attempt to write a tool to add files automatically: 
> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a 
> tool becomes easier if it would only modify one source of truth and generates 
> all other artifacts such as Xcode projects from it.
> 
> I don't want build file's syntax to be so human unfriendly that I need a tool 
> for it.
> 
> Often times, these syntax problems can be improved dramatically by simple 
> changes. e.g. we had a similar discussion about TestExpectation syntax, and 
> I'm much happier with the new syntax even though the new syntax is 
> functionally equivalent to the old one, and two syntaxes are very similar.
> 
> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
> I’ve experimented with this in the past and you’re right that it shouldn’t be 
> particularly difficult to do. However, I suspect that the task would be 
> similar in scope to defining an improved syntax for gyp. And if the syntax is 
> the primary sticking point with gyp then it’d seem preferable to tackle 
> initially.
> 
> Yeah. In fact, we can just come up with whatever syntax we like and convert 
> it to the existing gyp format if the syntax was the biggest issue.

Do we want to define the whole build system (including information how to 
invoke the generators) with the new system, or is a "simple" list for the input 
files sufficient? IMHO adding a new generator build step happens very rarely. 
So maybe we can spit the "input file list" (mainly *.cpp and *.idl) into new 
files.
Then GYP and CMake can read them and generate the build system out of them 
directly (like they to already today) instead of listing the files in the 
*.gpyi and *.cmake. This might work for other systems like qmake too.
For XCode we can maybe have a "template XCode project" and generate the "work 
XCode project" with a script. This script then only need to fill in the files 
from the "input file list" into the "template XCode project".
Defining the feature flags can be done like Maciej suggested with "Port.h" 
files.

-- Patrick___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger wrote:

> Another option is to add a webkit-patch command for modifying the build
> files. That way, the syntax doesn't need to be overly human friendly. There
> was also some attempt to write a tool to add files automatically:
> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
> tool becomes easier if it would only modify one source of truth and
> generates all other artifacts such as Xcode projects from it.
>

I don't want build file's syntax to be so human unfriendly that I need a
tool for it.

Often times, these syntax problems can be improved dramatically by simple
changes. e.g. we had a similar discussion about TestExpectation syntax, and
I'm much happier with the new syntax even though the new syntax is
functionally equivalent to the old one, and two syntaxes are very similar.

On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:

> I’ve experimented with this in the past and you’re right that it shouldn’t
> be particularly difficult to do. However, I suspect that the task would be
> similar in scope to defining an improved syntax for gyp. And if the syntax
> is the primary sticking point with gyp then it’d seem preferable to tackle
> initially.
>

Yeah. In fact, we can just come up with whatever syntax we like and convert
it to the existing gyp format if the syntax was the biggest issue.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 10:12 AM, Mark Rowe  wrote:

>
> On 2013-01-31, at 00:59, Jochen Eisinger  wrote:
>
>
>
> On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe  wrote:
>
>>
>> On 2013-01-31, at 00:48, Adam Barth  wrote:
>>
>> >>> I would consider changing or improving gyp's syntax to be on the table
>> >>> if it was needed to reach the goal.
>> >>
>> >> For what it’s worth, I also find the gyp syntax to be unpleasant. It
>> feels as though it was optimized for being processed by a machine rather
>> than for being written and maintained by humans.
>> >
>> > Unlike xcodeproj files.  :)
>>
>> Don’t get me wrong, Xcode projects suck for hand-editing too. However,
>> they’re not intended to be edited by hand. Gyp files are, and so the
>> expected level of human readability is much higher.
>>
>
> Many of us are actually editing the Xcode projects by hand, either because
> they don't have Xcode or don't know how to use it. (Yes, that includes
> coming up with a bunch of new UUIDs by hand)
>
>
> I wasn’t trying to suggest that current situation is a good one, only that
> if it would be easier to get momentum on switching to something like gyp if
> the replacement’s syntax was friendlier. Particularly when the people that
> need to be convinced to switch, and who’ll have to adapt their workflow,
> are those that are editing the project files in a nice GUI.
>

Agreed.

Another option is to add a webkit-patch command for modifying the build
files. That way, the syntax doesn't need to be overly human friendly. There
was also some attempt to write a tool to add files automatically:
https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
tool becomes easier if it would only modify one source of truth and
generates all other artifacts such as Xcode projects from it.

best
-jochen



>
> - Mark
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Mark Rowe]

On 2013-01-31, at 01:07, Hajime Morrita  wrote:

> In my understanding, it doesn't matter whether Apple Mac port supports ninja 
> or not. We could use GNU make if some meta-build system is adopted because 
> Mac OS has it installed. The problem here is that the neither CMake and GYP 
> isn't easy to adopt for reasons discussed in this thread.

As I mentioned in an earlier email, we need to keep the Mac port building via 
Xcode for our production builds.

> My personal feeling is that we could build a simple meta build system which 
> specifically targetsMac WebKit and XCode.
> 
> It could be just a little more than a templating system which generates the 
> list of files plus their UUIDs. The tool doesn't need to be so general like 
> CMake/GYP. Many tricky configuration things could be in the hard-coded 
> boilerplate. It could just focus on generating file list and UUIDs. It's 
> something like project.pbxproj.in and its preprocessor.
> 
> It won't be a direct step toward the unified build system. But we'll figure 
> out the next step once the build is represented by a simple plain text.

I’ve experimented with this in the past and you’re right that it shouldn’t be 
particularly difficult to do. However, I suspect that the task would be similar 
in scope to defining an improved syntax for gyp. And if the syntax is the 
primary sticking point with gyp then it’d seem preferable to tackle initially.

I should also clarify that I don’t think gyp’s current syntax is a showstoppper 
for adoption. I’d just like to see it improved.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Mark Rowe]

On 2013-01-31, at 00:59, Jochen Eisinger  wrote:

> 
> 
> On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe  wrote:
> 
> On 2013-01-31, at 00:48, Adam Barth  wrote:
> 
> >>> I would consider changing or improving gyp's syntax to be on the table
> >>> if it was needed to reach the goal.
> >>
> >> For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
> >> as though it was optimized for being processed by a machine rather than 
> >> for being written and maintained by humans.
> >
> > Unlike xcodeproj files.  :)
> 
> Don’t get me wrong, Xcode projects suck for hand-editing too. However, 
> they’re not intended to be edited by hand. Gyp files are, and so the expected 
> level of human readability is much higher.
> 
> Many of us are actually editing the Xcode projects by hand, either because 
> they don't have Xcode or don't know how to use it. (Yes, that includes coming 
> up with a bunch of new UUIDs by hand)


I wasn’t trying to suggest that current situation is a good one, only that if 
it would be easier to get momentum on switching to something like gyp if the 
replacement’s syntax was friendlier. Particularly when the people that need to 
be convinced to switch, and who’ll have to adapt their workflow, are those that 
are editing the project files in a nice GUI.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Hajime Morrita]

In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:

> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> >> CMake was originally considered a non-starter for chromium since the
> >> XCode and VS projects it produced didn't look or feel like native
> >> projects. However, we've since switched to ninja for most things so
> >> I'm less sure how important this is now. I've never been a huge fan of
> >> the CMake syntax but I haven't used it enough to really have an
> >> informed opinion.
> >
> > Generating well-structured Xcode projects is still something that is
> important for any meta build system that we would consider adopting for the
> Mac. It would be substantially more challenging for us to support an
> alternative system for building our production builds. If there are
> substantial advantages to using ninja for engineering builds then we may
> wish to support both to get the best behavior in each environment.
> >
> > The non-natively structured Xcode projects is one thing that turned me
> off CMake when I looked at it in the past. I’m not sure if this has
> improved since then. If not, then I don’t think CMake is worth spending
> much time on.
>
> If you want to commit the generated projects CMake isn't an option anyway,
> since it uses absolute paths and also requires a cmake binary on the
> machine used for compiling (to support all CMake features across all
> generators). This tight integration is usually a big win, since the
> CMakeLists.txt files are part of the build system they can be changed
> directly in the IDE and update the project without invoking external tools.
>
> Only for my personal interest: What do you mean exactly with non-natively
> structured Xcode projects? CMake aims to support a native IDE feel as far
> as possible. Would be great if you explain that to me (off-list) to get
> CMake improved for XCode?
>
> >> Regarding "(b) The generated project invokes only tools that are part
> >> of the default Mac OS X install": invoking tools that are checked into
> >> the WK repo is also possible, right, since we invoke scripts now? So,
> >> hypothetically, could we check in a copy of the ninja binary and build
> >> with that?
> >
> > Checking in binaries isn’t an option for us, and isn’t a particularly
> scalable approach anyway given the number of platforms that WebKit can
> build on. If we require an external tool as a dependency to build WebKit
> from source then we’d need to check in the source for the tool and build it
> prior to building WebKit proper. This obviously introduces more complexity
> so it would be preferable to keep the dependencies to a minimum.
>
> Maybe you can check in the ninja source and compile it during build. It
> only requires python (and hopefully installed build tools) to get built.
>
> -- Patrick
> ___
> 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

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Hajime Morrita]

On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:

> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> >> CMake was originally considered a non-starter for chromium since the
> >> XCode and VS projects it produced didn't look or feel like native
> >> projects. However, we've since switched to ninja for most things so
> >> I'm less sure how important this is now. I've never been a huge fan of
> >> the CMake syntax but I haven't used it enough to really have an
> >> informed opinion.
> >
> > Generating well-structured Xcode projects is still something that is
> important for any meta build system that we would consider adopting for the
> Mac. It would be substantially more challenging for us to support an
> alternative system for building our production builds. If there are
> substantial advantages to using ninja for engineering builds then we may
> wish to support both to get the best behavior in each environment.
> >
> > The non-natively structured Xcode projects is one thing that turned me
> off CMake when I looked at it in the past. I’m not sure if this has
> improved since then. If not, then I don’t think CMake is worth spending
> much time on.
>
> If you want to commit the generated projects CMake isn't an option anyway,
> since it uses absolute paths and also requires a cmake binary on the
> machine used for compiling (to support all CMake features across all
> generators). This tight integration is usually a big win, since the
> CMakeLists.txt files are part of the build system they can be changed
> directly in the IDE and update the project without invoking external tools.
>
> Only for my personal interest: What do you mean exactly with non-natively
> structured Xcode projects? CMake aims to support a native IDE feel as far
> as possible. Would be great if you explain that to me (off-list) to get
> CMake improved for XCode?
>
> >> Regarding "(b) The generated project invokes only tools that are part
> >> of the default Mac OS X install": invoking tools that are checked into
> >> the WK repo is also possible, right, since we invoke scripts now? So,
> >> hypothetically, could we check in a copy of the ninja binary and build
> >> with that?
> >
>
> Checking in binaries isn’t an option for us, and isn’t a particularly
> scalable approach anyway given the number of platforms that WebKit can
> build on. If we require an external tool as a dependency to build WebKit
> from source then we’d need to check in the source for the tool and build it
> prior to building WebKit proper. This obviously introduces more complexity
> so it would be preferable to keep the dependencies to a minimum.
>
> Maybe you can check in the ninja source and compile it during build. It
> only requires python (and hopefully installed build tools) to get built.


In my understanding, it doesn't matter whether Apple Mac port supports
ninja or not. We could use GNU make if some meta-build system is adopted
because Mac OS has it installed. The problem here is that the neither CMake
and GYP isn't easy to adopt for reasons discussed in this thread.

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


> -- Patrick
> ___
> 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

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Jochen Eisinger]

On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe  wrote:

>
> On 2013-01-31, at 00:48, Adam Barth  wrote:
>
> >>> I would consider changing or improving gyp's syntax to be on the table
> >>> if it was needed to reach the goal.
> >>
> >> For what it’s worth, I also find the gyp syntax to be unpleasant. It
> feels as though it was optimized for being processed by a machine rather
> than for being written and maintained by humans.
> >
> > Unlike xcodeproj files.  :)
>
> Don’t get me wrong, Xcode projects suck for hand-editing too. However,
> they’re not intended to be edited by hand. Gyp files are, and so the
> expected level of human readability is much higher.
>

Many of us are actually editing the Xcode projects by hand, either because
they don't have Xcode or don't know how to use it. (Yes, that includes
coming up with a bunch of new UUIDs by hand)

best
-jochen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Mark Rowe]

On 2013-01-31, at 00:48, Adam Barth  wrote:

>>> I would consider changing or improving gyp's syntax to be on the table
>>> if it was needed to reach the goal.
>> 
>> For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
>> as though it was optimized for being processed by a machine rather than for 
>> being written and maintained by humans.
> 
> Unlike xcodeproj files.  :)

Don’t get me wrong, Xcode projects suck for hand-editing too. However, they’re 
not intended to be edited by hand. Gyp files are, and so the expected level of 
human readability is much higher.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Patrick Gansterer]

Hi,

Am 31.01.2013 um 09:25 schrieb Mark Rowe:
>> CMake was originally considered a non-starter for chromium since the
>> XCode and VS projects it produced didn't look or feel like native
>> projects. However, we've since switched to ninja for most things so
>> I'm less sure how important this is now. I've never been a huge fan of
>> the CMake syntax but I haven't used it enough to really have an
>> informed opinion.
> 
> Generating well-structured Xcode projects is still something that is 
> important for any meta build system that we would consider adopting for the 
> Mac. It would be substantially more challenging for us to support an 
> alternative system for building our production builds. If there are 
> substantial advantages to using ninja for engineering builds then we may wish 
> to support both to get the best behavior in each environment.
> 
> The non-natively structured Xcode projects is one thing that turned me off 
> CMake when I looked at it in the past. I’m not sure if this has improved 
> since then. If not, then I don’t think CMake is worth spending much time on.

If you want to commit the generated projects CMake isn't an option anyway, 
since it uses absolute paths and also requires a cmake binary on the machine 
used for compiling (to support all CMake features across all generators). This 
tight integration is usually a big win, since the CMakeLists.txt files are part 
of the build system they can be changed directly in the IDE and update the 
project without invoking external tools.

Only for my personal interest: What do you mean exactly with non-natively 
structured Xcode projects? CMake aims to support a native IDE feel as far as 
possible. Would be great if you explain that to me (off-list) to get CMake 
improved for XCode?

>> Regarding "(b) The generated project invokes only tools that are part
>> of the default Mac OS X install": invoking tools that are checked into
>> the WK repo is also possible, right, since we invoke scripts now? So,
>> hypothetically, could we check in a copy of the ninja binary and build
>> with that?
> 
> Checking in binaries isn’t an option for us, and isn’t a particularly 
> scalable approach anyway given the number of platforms that WebKit can build 
> on. If we require an external tool as a dependency to build WebKit from 
> source then we’d need to check in the source for the tool and build it prior 
> to building WebKit proper. This obviously introduces more complexity so it 
> would be preferable to keep the dependencies to a minimum.

Maybe you can check in the ninja source and compile it during build. It only 
requires python (and hopefully installed build tools) to get built.

-- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Adam Barth]

On Thu, Jan 31, 2013 at 12:25 AM, Mark Rowe  wrote:
> On 2013-01-30, at 17:14, Dirk Pranke  wrote:
>> On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak  wrote:
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
> Thanks for sharing this.
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>
> I wish we only had one build system (it were easy to add/remove/move 
> files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has 
> chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it 
> took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to 
> kill
> WebCore/platform.
>
>
> +1
>
> This is a hard problem.  It is a problem worth solving.
>
> Do you have more thoughts on this, particularly since you know quite well
> how both Xcode and gyp work?
>
> I suspect this is one of those things that it would be hard to achieve
> consensus on since there are so many stakeholders.  But it may be fruitful
> to have a "what if" discussion about what this might look like.
>

 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.

 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?

 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...
>>>
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port 
>>> checked in to source control.
>>> (b) The generated project invokes only tools that are part of the default 
>>> Mac OS X install.
>>>
>>> It may not be completely impossible to violate these requirements but it 
>>> will require a lot of bureaucracy.
>>>
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).

 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.

 I suggest if there is interest in this we can start a new thread to
 discuss further ...
>>>
>>> My preference would be to use a common meta-build system with a comfortably 
>>> human-readable and human-editable syntax, and checked in generated project 
>>> files for those ports that need them.
>>>
>>> I think a key to making this work is to get Chromium and the Apple Mac port 
>>> onto a common build system, which will probably require both Google and 
>>> Apple ponying up at least one person to work on this project for a 
>>> reasonable period of time.
>>>
>>> I think the plausible meta-build-systems to use would be CMake and Gyp, but 
>>> in both cases it may be necessary to modify them to work well for everyone.
>>>
>>
>> Premake might also be an option, though I wouldn't necessarily vote
>> for it. Gyp's syntax is ... awkward ... but apart from that might just
>> work for checking in generated apple mac xcode projects. We should try
>> it (shouldn't be too hard, since abarth had it working at one point).
>
> I think Eric and/or Adam had JavaScriptCore building with gyp at one point. 
> I’m not sure if they ever got to the other projects.

We had JavaScriptCore and WebCore working.  (We also had
JavaScriptGlue, but that doesn't exist anymore.)  I don't remember if
we had WebKit/mac working.  (WebKit2 didn't exist at the time.)

>> I would consider changing or improving gyp's syntax to be on the table
>> if it was needed to reach the goal.
>
> For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as 
> though it was optimized for being processed by a machine rather than for 
> being written and maintained

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Mark Rowe]

On 2013-01-30, at 17:14, Dirk Pranke  wrote:

> On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak  wrote:
>> 
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>> 
>>> On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
 Thanks for sharing this.
 
 On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
 
 I wish we only had one build system (it were easy to add/remove/move 
 files).
 
 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
 WebCore/platform.
 
 
 +1
 
 This is a hard problem.  It is a problem worth solving.
 
 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?
 
 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be fruitful
 to have a "what if" discussion about what this might look like.
 
>>> 
>>> I think we can solve this problem if we agree that we want to. I think
>>> we haven't in the past mostly because we couldn't reach a consensus
>>> that it was worth solving enough to really try.
>>> 
>>> I would love to see this fixed and would be glad to work on it. I
>>> think we should at least pursue this far enough to fully understand
>>> what our options are and what the costs and tradeoffs might be; does
>>> anyone disagree, and is anyone else willing to help pitch in?
>>> 
>>> I think there are several possible ways we could solve this. One would
>>> be to switch to a common meta-build system. My understanding is that
>>> Apple's internal production build processes impose certain constraints
>>> here that I don't fully understand, but I know we've discussed the
>>> possibility of checking in generated project files as a workaround.
>>> Maybe there are other options as well to those constraints? I would
>>> love to discuss this further w/ someone from Apple ...
>> 
>> It's far simplest for us if:
>> (a) There is an Xcode project (or a Makefile) that builds the Mac port 
>> checked in to source control.
>> (b) The generated project invokes only tools that are part of the default 
>> Mac OS X install.
>> 
>> It may not be completely impossible to violate these requirements but it 
>> will require a lot of bureaucracy.
>> 
>>> (Also, just to get this out of the way, I don't think gyp needs to be
>>> the solution).
>>> 
>>> Another alternative would be to write a script that did support at
>>> least the common use cases (add/move/delete files). There have been
>>> attempts in the past, but they have foundered on at least some
>>> perceived skepticism over how well this would work w/ XCode. That
>>> said, I don't think we've really pushed this to see. At some point
>>> this script might turn into a meta-meta-build system, which might be
>>> silly but also be the shortest path to the finish line.
>>> 
>>> I suggest if there is interest in this we can start a new thread to
>>> discuss further ...
>> 
>> My preference would be to use a common meta-build system with a comfortably 
>> human-readable and human-editable syntax, and checked in generated project 
>> files for those ports that need them.
>> 
>> I think a key to making this work is to get Chromium and the Apple Mac port 
>> onto a common build system, which will probably require both Google and 
>> Apple ponying up at least one person to work on this project for a 
>> reasonable period of time.
>> 
>> I think the plausible meta-build-systems to use would be CMake and Gyp, but 
>> in both cases it may be necessary to modify them to work well for everyone.
>> 
> 
> Premake might also be an option, though I wouldn't necessarily vote
> for it. Gyp's syntax is ... awkward ... but apart from that might just
> work for checking in generated apple mac xcode projects. We should try
> it (shouldn't be too hard, since abarth had it working at one point).

I think Eric and/or Adam had JavaScriptCore building with gyp at one point. I’m 
not sure if they ever got to the other projects.

> I would consider changing or improving gyp's syntax to be on the table
> if it was needed to reach the goal.

For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as 
though it was optimized for being processed by a machine rather than for being 
written and maintained by humans.

> CMake was originally considered a non-starter for chromium since the
> XCode and VS projects it produced didn't look or feel like native
> projects. However, we've since switched to ninja for most things so
> I'm less sure how important this is now. I've never been a huge fan of
> the CMake syntax but I haven't used it 

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 12:09 AM, Hajime Morrita  wrote:

> I did it for WTF and JSC with kevino@.
> https://bugs.webkit.org/show_bug.cgi?id=72855
> I hope I had had time to extend the work to WebCore, which was my original
> goal :-/
>
> I did it through an automation but the tool was so slow and hacky that it
> was not capable for large WebCore codebase.
>
> Seeing that the number of exported symbol is about 2700, manual work with
> regular expression will also work
> if it is OK to do the work incrementally... and if you are patient enough
> :-)
>

2700 is a lot of symbols to export! Perhaps we can reduce the number of
exported symbols? For example, we can move more code from WebKit into
WebCore to share more code between ports so that the API surface WebCore
has to expose will be smaller and more well defined.

I also bet there are quite few symbols we export from WebCore that are no
longer used in WebKit.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Hajime Morrita]

(From the right address)

I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/

I did it through an automation but the tool was so slow and hacky that it
was not capable for large WebCore codebase.

Seeing that the number of exported symbol is about 2700, manual work with
regular expression will also work
if it is OK to do the work incrementally... and if you are patient enough
:-)

--
morrita



On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa wrote:

> On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger wrote:
>
>> On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak  wrote:
>>
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>>>
>>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
>>> >> Thanks for sharing this.
>>> >>
>>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>>> >>
>>> >> I wish we only had one build system (it were easy to add/remove/move
>>> files).
>>> >>
>>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>>> >> unhealthy sign for the project.  Adam is not the only person who has
>>> chosen
>>> >> to empty files instead of removing them.  The pain of updating 8 build
>>> >> system is so great, we jump through hoops to avoid it.  Which means
>>> it took
>>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years
>>> to kill
>>> >> WebCore/platform.
>>> >>
>>> >>
>>> >> +1
>>> >>
>>> >> This is a hard problem.  It is a problem worth solving.
>>> >>
>>> >> Do you have more thoughts on this, particularly since you know quite
>>> well
>>> >> how both Xcode and gyp work?
>>> >>
>>> >> I suspect this is one of those things that it would be hard to achieve
>>> >> consensus on since there are so many stakeholders.  But it may be
>>> fruitful
>>> >> to have a "what if" discussion about what this might look like.
>>> >>
>>> >
>>> > I think we can solve this problem if we agree that we want to. I think
>>> > we haven't in the past mostly because we couldn't reach a consensus
>>> > that it was worth solving enough to really try.
>>> >
>>> > I would love to see this fixed and would be glad to work on it. I
>>> > think we should at least pursue this far enough to fully understand
>>> > what our options are and what the costs and tradeoffs might be; does
>>> > anyone disagree, and is anyone else willing to help pitch in?
>>> >
>>> > I think there are several possible ways we could solve this. One would
>>> > be to switch to a common meta-build system. My understanding is that
>>> > Apple's internal production build processes impose certain constraints
>>> > here that I don't fully understand, but I know we've discussed the
>>> > possibility of checking in generated project files as a workaround.
>>> > Maybe there are other options as well to those constraints? I would
>>> > love to discuss this further w/ someone from Apple ...
>>>
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>>> checked in to source control.
>>> (b) The generated project invokes only tools that are part of the
>>> default Mac OS X install.
>>>
>>
>> Another desirable property would be to move to a more automatic way of
>> handling exported symbols: Currently each port that depends on this feature
>> has its own .exp file or similar. I think if we could move to something
>> that would allow for changing WebCore API without having to touch all those
>> files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win
>>
>
> morrita already did this for WTF, and it works great for us. What's
> blocking us from doing the same for WebCore?
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Peripheral ports (was Re: WebKit Wishes)

[noam . rosenthal]

From: ext Eric Seidel mailto:e...@webkit.org>>

I wish we didn’t have to worry about platforms we couldn’t test.

It can’t be the job of the core maintainers to care about all the peripheral 
ports which contribute very little core code. Our code needs to be structured 
in such a manner that its easy for the core to march forward, while letting the 
ports catch up as they need to asynchronously.  Platform support code shouldn’t 
even need to be in webkit.org!  Porting 
webkit.org’s platform abstractions should be trivial, but 
core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium 
Linux) shouldn’t need to worry about keeping all ports working.
As someone who works on the "peripheral" ports quite a bit I would have to 
agree that this is not a good situation. I would prefer a situation where my 
core contributions are considered valuable, and my "peripheral ports" 
contribution are not considered taxing.

> I wish we only had one build system
I think that having one meta-build system might help this quite a bit.
But what would really help me is if I could have a better understanding of 
which parts of the code are taxing for Apple and Google. For example, in 2011 
Oliver Hunt has communicated that the Qt JSC bindings were too taxing, and ever 
since we've done a lot of work to reduce that tax 
(https://bugs.webkit.org/show_bug.cgi?id=60842). This was, to me, a productive 
communication about that problem.

> I wish I felt like reviewers understood/trusted each other more.
I think that if there was a clear and detailed communication about taxing 
properties of the "peripheral ports" or platform abstraction, perhaps in the 
form of bugs on bugzilla like the one I've mentioned, we can trust the 
contributors from the peripheral ports, together with everyone else, to find 
the right solutions.
How would it feel for people if we had something like a bugzilla 
component/topic to track those issues?

I think that solving those issues rather than pushing the peripheral ports to 
the side is in the benefit of the WebKit project, and is one of the things that 
differentiates it from projects like Mozilla that only support one company's 
browser(s). I'm hoping that other people see this value as well…

~Noam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev