Re: [webkit-dev] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

[Fujii Hironori]

On Fri, May 19, 2017 at 5:24 PM, Isaac Devine  wrote:
> On 19 May 2017 at 16:16, Fujii Hironori  wrote:
>>
> I have a linker warning because it was no longer linked to the
> MultiThreadedDLL, and was statically linked instead. The behavior described
> matched some issues I was having. I'm basically updating to the latest trunk
> of WebKit for the application and the /nodefaultlib changes have arrived
> after my previous snapshot.

Ah, that problem. Why don't you use /NODEFAULTLIB:LIBCMT switch?


>> > I've found bug https://bugs.webkit.org/show_bug.cgi?id=157067 which
>> > describe
>> > removing the /nodefaultlib for the libcmt (the MultiThreaded static
>> > libary),
>> > but in the comments they mention an eventual transition to the
>> > MultiThreaded
>> > CRT.
>> >
>> > Is that time now? :-)
>>
>>   Bug 170594 – [CMake][Windows] Use DLL CRT instead of static CRT
>>   https://bugs.webkit.org/show_bug.cgi?id=170594
>>
> Thanks I've attached my WIP patch for comparison, notably I modify some
> props files as well, but from your patch I'm guessing they aren't used
> anymore?

I don't know. Does Apple Internal Build use the files?
I'm waiting for AppleWin port folks looking into the bug. If you can't
wait for that, you need to switch to use DLL CRT only for WinCairo
port
This was my WIP patch .
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where do we put WPT tests to be exported

[youenn fablet]

> > Sure, it is good to test conformance, but there is no longer regression
> > testing on the deprecated feature behavior itself.
> > Ideally, this would require tighter syncing between the browsers. Might
> have
> > positive and/or negative consequences.
>
> I don't think we should be changing anything about our process to
> deprecate a feature based on changes to web platform tests or its
> limitations.
>

Agreed.


>
> If web platform tests end up deleting tests that we decide to continue
> to support, we should keep them elsewhere in WebKit repository instead
> of deleting those features.
>

Exactly, we should be ready for those cases.
When doing a full resync, it is just impossible to check whether each
modification is about feature removal.


> I would most vocally and strongly oppose to making any feature or
> policy decisions in WebKit solely based on changes to or processes in
> web platform tests.
>
> - R. Niwa
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where do we put WPT tests to be exported

[Ryosuke Niwa]

On Fri, May 19, 2017 at 10:17 AM, youenn fablet  wrote:
>
>
> Le ven. 19 mai 2017 à 09:44, Anne van Kesteren  a écrit :
>>
>> On Fri, May 19, 2017 at 5:11 PM, youenn fablet  wrote:
>> > When a spec gets updated, the WPT tests will ideally be updated at the
>> > same
>> > time.
>> > The updated tests will no longer ensure non-regression until the browser
>> > implements the new behavior.
>>
>> Ideally if importing test updates results in failures those end up
>> being tracked as new bugs. I realize that's not how it works today,
>> but that's how it should work I think.
>
>
> Right, and that is very good as long as there is effort to match the
> implementation with the spec.
> Until the bug is fixed, regressions related to the no-longer compliant
> behavior might not be caught by WPT.
>
>>
>>
>>
>> > The same applies to deprecated features for which WPT tests might be
>> > removed
>> > for instance.
>>
>> In this case it's expected that a "historical" test is added that
>> tests the feature isn't supported, so there's still coverage.
>
>
> Sure, it is good to test conformance, but there is no longer regression
> testing on the deprecated feature behavior itself.
> Ideally, this would require tighter syncing between the browsers. Might have
> positive and/or negative consequences.

I don't think we should be changing anything about our process to
deprecate a feature based on changes to web platform tests or its
limitations.

If web platform tests end up deleting tests that we decide to continue
to support, we should keep them elsewhere in WebKit repository instead
of deleting those features.

I would most vocally and strongly oppose to making any feature or
policy decisions in WebKit solely based on changes to or processes in
web platform tests.

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

Re: [webkit-dev] Where do we put WPT tests to be exported

[youenn fablet]

Le ven. 19 mai 2017 à 09:44, Anne van Kesteren  a écrit :

> On Fri, May 19, 2017 at 5:11 PM, youenn fablet  wrote:
> > When a spec gets updated, the WPT tests will ideally be updated at the
> same
> > time.
> > The updated tests will no longer ensure non-regression until the browser
> > implements the new behavior.
>
> Ideally if importing test updates results in failures those end up
> being tracked as new bugs. I realize that's not how it works today,
> but that's how it should work I think.
>

Right, and that is very good as long as there is effort to match the
implementation with the spec.
Until the bug is fixed, regressions related to the no-longer compliant
behavior might not be caught by WPT.


>
>
> > The same applies to deprecated features for which WPT tests might be
> removed
> > for instance.
>
> In this case it's expected that a "historical" test is added that
> tests the feature isn't supported, so there's still coverage.
>

Sure, it is good to test conformance, but there is no longer regression
testing on the deprecated feature behavior itself.
Ideally, this would require tighter syncing between the browsers. Might
have positive and/or negative consequences.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where do we put WPT tests to be exported

[Anne van Kesteren]

On Fri, May 19, 2017 at 5:11 PM, youenn fablet  wrote:
> When a spec gets updated, the WPT tests will ideally be updated at the same
> time.
> The updated tests will no longer ensure non-regression until the browser
> implements the new behavior.

Ideally if importing test updates results in failures those end up
being tracked as new bugs. I realize that's not how it works today,
but that's how it should work I think.


> The same applies to deprecated features for which WPT tests might be removed
> for instance.

In this case it's expected that a "historical" test is added that
tests the feature isn't supported, so there's still coverage.


> I don't know what WPT can do there. This issue is probably limited in
> practice.

Modifying tests doesn't happen often, but it definitely does happen
and it would be nice if infrastructure accounted for it. (I've often
added additional assertions or additional tests to an existing
resource.)


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

Re: [webkit-dev] Where do we put WPT tests to be exported

[youenn fablet]

Le jeu. 18 mai 2017 à 05:09, Philip Jägenstedt  a écrit :

>
>> FWIW, I think it makes sense to treat wpt as both regression tests and
> conformance tests. They're regression tests because they can in fact catch
> regressions. And they're conformance tests because they're supposed to be
> derived from the specs, and that should be true of local modifications as
> well if they're intended to be upstreamed.
>
>
When a spec gets updated, the WPT tests will ideally be updated at the same
time.
The updated tests will no longer ensure non-regression until the browser
implements the new behavior.
The same applies to deprecated features for which WPT tests might be
removed for instance.
I don't know what WPT can do there. This issue is probably limited in
practice.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

[Isaac Devine]

On 19 May 2017 at 16:16, Fujii Hironori  wrote:

> On Fri, May 19, 2017 at 8:18 AM, Isaac Devine 
> wrote:
> > Hi,
> >
> > I'm looking at linking against WebKit in my application, which is linked
> > against the MultiThreadedDLL CRT (i.e. dynamically linked); however
> WebKit
> > is linked against the MultiThreaded CRT (i.e. statically linked). I've
> > linked against previous builds with this configuration "without
> problems".
>
> What problem do you have. It should not cause any problem by using any
> type of CRT in WebKit.dll except this problem
> .
>

I have a linker warning because it was no longer linked to the
MultiThreadedDLL, and was statically linked instead. The behavior described
matched some issues I was having. I'm basically updating to the latest
trunk of WebKit for the application and the /nodefaultlib changes have
arrived after my previous snapshot.


> > I've found bug https://bugs.webkit.org/show_bug.cgi?id=157067 which
> describe
> > removing the /nodefaultlib for the libcmt (the MultiThreaded static
> libary),
> > but in the comments they mention an eventual transition to the
> MultiThreaded
> > CRT.
> >
> > Is that time now? :-)
>
>   Bug 170594 – [CMake][Windows] Use DLL CRT instead of static CRT
>   https://bugs.webkit.org/show_bug.cgi?id=170594
>
> Thanks I've attached my WIP patch for comparison, notably I modify some
props files as well, but from your patch I'm guessing they aren't used
anymore?

>
> > I've been making local changes to do this and have noticed in the cmake
> > files that a few of them will swap out the Debug versions of the CRT for
> the
> > release ones, is there a specific reason for that?
>
> The debug CRT makes WebKit unbearably slow.
>
> Makes sense.

>
> > Additionally, relating to the /nodefaultlib directives that are present
> in
> > several build files; my understanding is that if all of the projects were
> > compiled against the same CRT these can be removed?
>
> I think so, too.
>
> > From my reading of bug
> > 157067, I believe that the nodefaultlib directives have hidden bugs in
> the
> > past, is that correct?
>
> ---
> Fujii Hironori
> Sony Interactive Entertainment Inc.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev