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 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.
On Wed, Jan 30, 2013 at 3:24 PM, Patrick Gansterer wrote:
> Hi,
>
> Am 30.01.2013 um 22:28 schrieb Eric Seidel:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
>
> I've created CMake files for two different ports at [1] and [2] already, but
> did't get positive f
On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez wrote:
> Hi Eric,
>
> On Wed, Jan 30, 2013 at 10: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 ve
On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak wrote:
>
> Hi Eric,
>
> These are great thoughts. I agree with you on all points. One informative
> comment below:
>
> 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)
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
On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel wrote:
> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols. If both were to
> convert to using EXPORT decorators instead, then we could remove needs for
> fixing export l
I should have been more clear. By "which require lists of exported
symbols", I meant "which require lists of exported symbols for WebCore".
The Internals discussion is obviously about WebCore symbols which are
exported through WebKit as well. It seems no other symbols from WebCore
should ever be
What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols. If both were to
convert to using EXPORT decorators instead, then we could remove needs for
fixing export lists.
Please correct me if I've misunderstood.
Other ports (
+1
Ninja is beyond-words amazing. http://martine.github.com/ninja/ For
better or worse, it is not designed to use human-editable build files,
but rather to be used by a meta build system, like GYP or CMake. So
using ninja is really an orthogonal discussion to the "single build
system" discussio
On Sat, Feb 2, 2013 at 4:16 PM, James Robinson wrote:
>
>
> On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen wrote:
>
>> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>>
>>>
>>> It would be nice if, in the shared library build of chromium, webcore
>>> and perhaps the modules and platform were separa
On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth wrote:
> Ninja has extremely fast incremental builds and can be generated by
> GYP. Here are some stats from a year ago:
>
> https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
>
> Ninja has gotten even faster since then. If you're intereste
Ninja has extremely fast incremental builds and can be generated by
GYP. Here are some stats from a year ago:
https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
Ninja has gotten even faster since then. If you're interested in
trying it out, you can play around with incremental buil
On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen wrote:
> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>
>>
>> It would be nice if, in the shared library build of chromium, webcore and
>> perhaps the modules and platform were separate DLLs.
>>
>>
> The shared library build is kind of a developer bui
On 02/01/2013 02:28 AM, Darin Fisher wrote:
It would be nice if, in the shared library build of chromium, webcore
and perhaps the modules and platform were separate DLLs.
The shared library build is kind of a developer build, right? In this
case I believe you can solve this by setting the
I think one important aspect of build systems was not considered yet int
this conversation: speed. The time an incremental build takes has a
great effect on developer productivity. I don't think any of the
meta-build systems we use does a great job here - although I only have
experiences with q
Sounds good to me as well.
-Sam
On Jan 30, 2013, at 3:54 PM, Nico Weber wrote:
> Hi,
>
> I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
> nobody ever shipped this and nobody intents to. Please speak up if
> you'd like that code to stick around.
>
> Nico
> _
16 matches
Mail list logo
