Re: [webkit-dev] Using C++20 in WebKit

2021-12-07 Thread Fujii Hironori via webkit-dev
On Tue, Dec 7, 2021 at 8:07 AM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I’m also excited about using coroutines in WebKit.  If there is already a
> GCC requirement for using a compiler that supports C++20, is there a reason
> not to switch from C++17 to C++20 later in 2021?
>
>
Will you change WebKit's GCC version policy?
If so, what will be the minimum supported versions of GCC, Clang and MSVC?

According to the Clang C++ conformance page, it doesn't fully support
Coroutines yet.
Do you know  which Clang version has started to support it partially?
Which part of Coroutines is supported by the version of Clang?

WebKitGTK/GCCRequirement – WebKit
https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Clang - C++ Programming Language Status
https://clang.llvm.org/cxx_status.html

C++ Standards Support in GCC - GNU Project
https://gcc.gnu.org/projects/cxx-status.html

Microsoft C/C++ language conformance | Microsoft Docs
https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WPT first test policy proposal

2021-11-20 Thread Fujii Hironori via webkit-dev
It sounds a good idea. It'd be nice to be documented in the web site for
new contributors.
https://webkit.org/testing-contributions/

Do we need another WPT-exemption-reason 'non-standards' for WebKit specific
features?

I think WPT-exemption-reason should be in the test case rather than
ChangeLog.
It's easy to know what WPT-exemption-reason is the file you are watching.
It's easy to know how many WPT-exemption-reason:urgency test cases are
remaining by grepping.

On Sat, Nov 20, 2021 at 6:06 AM Tim Nguyen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
>
In addition:
>
> WPT-PR: https://github.com/web-platform-tests/wpt/pulls/XX must be
> present in LayoutTests/imported/w3c/Changelog, this is to ensure tests are
> not lost at the next import.
>

Who will do the next import? Will someone update all test cases linked by
the WPT-PR line after the test case is committed to WPT repo? Or, will
someone update all test cases periodically?

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


Re: [webkit-dev] Replacing PHP with Python in Layout Tests

2021-02-01 Thread Fujii Hironori via webkit-dev
On Tue, Feb 2, 2021 at 7:14 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello Contributors,
>
> To help reduce the number of dependencies WebKit’s tools have, I would
> like to replace our PHP tests (and resources used by tests) with Python 3
> CGI scripts. I’ve already attempted to convert a few dozen PHP tests and
> resources to demonstrate that this is both possible and that the resulting
> Python is comparable to the existing PHP. Additionally, as advertised in
> Big Sur, PHP is only included for compatibility with legacy software and is
> not recommended.
>
> There are still a few issues to resolve (namely, an issue with Python 3 on
> some of our Windows machines), in the mean time, I want to determine if
> other platforms have any issues with replacing our PHP tests with Python 3.


  BTW, after you finish the task, can we remove Python 2 supports from all
Python scripts? Or, should we keep Python 2&3 support until Mojave support
ends?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-17 Thread Fujii Hironori
On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig  wrote:

>
> What are your thoughts on this?
>

I'm disappointed. I want to use CMake for all ports.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit Transition to Git

2020-10-16 Thread Fujii Hironori
According to this Jonathan's bugzilla comment, a new git repository will be
reconstructed.
https://bugs.webkit.org/show_bug.cgi?id=214957#c12

It'd be nice if commit-qu...@webkit.org is replaced by real authors.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit Transition to Git

2020-10-05 Thread Fujii Hironori
On Tue, Oct 6, 2020 at 12:40 AM Jonathan Bedard  wrote:

>
> That's one solution, but even that is somewhat insufficient because we
> don’t want to give someone access to every security issue just to give
> access to a single one. One of the solutions we’ve discussed is to migrate
> bugs component by component, the security component may stay on bugzilla
> indefinitely.
>
>
 I don't like this idea of using GitHub issue tracker and Bugzilla
together. Let's keep using Bugzilla for all components.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Could use some help from people who care about the WinCairo port

2020-09-12 Thread Fujii Hironori
Please disable the precompiled header for Windows DumpRenderTree at the
moment. I'll look into it next Monday.

WEBKIT_ADD_PRECOMPILED_HEADER("DumpRenderTreePrefix.h"
"win/DumpRenderTreePrefix.cpp" DumpRenderTree_SOURCES)

On Sun, Sep 13, 2020 at 7:13 AM Darin Adler  wrote:

> The patch for this bug
>
> https://bugs.webkit.org/show_bug.cgi?id=216428
>
> is failing to build on WinCairo because of some kind of precompiled header
> problem. I could use some help figuring out what I did wrong.
>
> — Darin
> ___
> 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] PSA: Bit fields won't be packed on Windows if you mix types

2020-09-04 Thread Fujii Hironori
On Fri, Sep 4, 2020 at 2:56 PM Ryosuke Niwa  wrote:

> On Thu, Sep 3, 2020 at 10:11 PM Fujii Hironori 
> wrote:
>
>>
>> On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:
>>
>>> Consecutive bit fields must use the same type.
>>>
>>
>> RenderLayer is mixing bool and unsigned in the consecutive bit fields.
>> They should use only uint8_t, right?
>>
>> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
>>
>
> Under the proposed coding style guide, yes, although I highly doubt the
> size of RenderLayer really matters.
>
>
Do you mean your new rule is applicable only for performance
critical parts?

BTW, I don't like to idea adding a new rule, but keeping old
style code. It introduces divergence between the guideline and
actual code. Do we really need a new rule that one doesn't
necessary have to follow?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

2020-09-03 Thread Fujii Hironori
On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:

> Consecutive bit fields must use the same type.
>

RenderLayer is mixing bool and unsigned in the consecutive bit fields. They
should use only uint8_t, right?
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

2020-07-16 Thread Fujii Hironori
I'm glad to hear various opinions. Slack still can't beat mailing lists for
technical discussions.

On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro 
wrote:

> Also, some packagers used to carry assorted downstream patches for build
> issues related to unification build which have not been needed anymore.
>

Unified source builds can have performance merit.
The SQLite Amalgamation makes it 5% and 10% faster.
https://www.sqlite.org/amalgamation.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

2020-07-14 Thread Fujii Hironori
On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig  wrote:

> While I don’t want to take away from what Darin is saying here about
> correct usage of forward declaration and , I’d like to
> understand why we have two different compilation models supported in
> WebKit. Is there a reason both need to be supported? Can we remove one?
>


I also want to know that. Does anyone still need non-unified builds?

I introduced other unnecessary header inclusion, and Darin asked me to fix
it.
https://bugs.webkit.org/show_bug.cgi?id=214204#c25
Reducing header inclusion can easily cause build breakages for non-unified
builds.
So, I fixed non-unified build breakage in r264332 and r264333 as the
preparation for that.
Non-unified builds was more broken than I expected. Does anyone still need
it?
Should we maintain non-unified builds until C++20 modules will nullify
unified builds?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Adrian Perez de Castro is now a WebKit reviewer

2019-10-14 Thread Fujii Hironori
Congratulations, Adrian 

On Mon, Oct 14, 2019 at 11:57 PM Caio Lima  wrote:

> Congratulations Adrian!
>
> Em seg, 14 de out de 2019 às 15:17, Carlos Alberto Lopez Perez <
> clo...@igalia.com> escreveu:
>
>> Hi everyone,
>>
>> I would like to announce that Adrian Perez de Castro (aperezdc on #webkit)
>> is now a WebKit reviewer.
>>
>> Adrian has several years of experience working with the WebKitGTK and WPE
>> WebKit ports. He is the release manager of the WPE port and the main
>> developer
>> behind the Cog WPE browser.
>>
>>
>> Please join me in congratulating Adrian, and send him some patches to
>> review.
>>
>>
>> Adrian, congratulations.
>>
>>
>> Cheers!
>>
>> ___
>> 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] Moving to Python 3

2019-07-16 Thread Fujii Hironori
On Sun, Jul 14, 2019 at 7:44 AM Ryosuke Niwa  wrote:

>
> I don’t think anyone is arguing that we’d eventually need to move to
> Python3. I’m arguing that it’s not okay to require random WebKit
> contributor to know some obscure python insanity to install Python 3, or
> have a script that installs Python 3 and breaks all other python scripts in
> the system.
>
>
 Just out of curiosity. As far as I know, installing Python 3 breaks
nothing. What and why are they got broken?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-27 Thread Fujii Hironori
Good news! Use CMake 3.14.5 to avoid another incremental build issue.

Bug 198850 – [CMake][Win] WTF_CopyHeaders copies files everytime in
incremental builds if Visual Studio generator is used
https://bugs.webkit.org/show_bug.cgi?id=198850


On Fri, Jun 28, 2019 at 1:21 AM Brent Fulgham  wrote:

> Apple is in the process of bringing up VS2019 now. I would be in favor of
> moving the minimum to 3.14 so we can safely support VS2019 compiles.
>
> -Brent
>
> On Jun 24, 2019, at 8:21 PM, Fujii Hironori 
> wrote:
>
> Hi,
>
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
>
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181
>
>
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
>
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
>
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>
> Happy WebKit 18th
> <https://webkit.org/blog/6888/celebrating-15-years-of-webkit/>birthday
> <https://donmelton.com/2017/06/25/sweet-sixteen-for-safari-and-webkit/>
>
> -- Fujii
> ___
> 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] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-26 Thread Fujii Hironori
jsc-i368 EWS is still failing.
Who is igalia-jsc-i386-ews bot maintainer?

On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
wrote:

> Hi,
>
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
>
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181
>
>
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
>
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
>
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>
> Happy WebKit 18th
> <https://webkit.org/blog/6888/celebrating-15-years-of-webkit/>birthday
> <https://donmelton.com/2017/06/25/sweet-sixteen-for-safari-and-webkit/>
>
> -- Fujii
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-24 Thread Fujii Hironori
Hi,

I'm going to bump cmake_minimum_required version to 3.10 for
shining new features.

Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
https://bugs.webkit.org/show_bug.cgi?id=199181


GTK and WPE's EWS and BuildBot bots maintainers, could you please
update your CMake on your bots?

If you are using CMake Visual Studio generator, you need CMake
3.12 or newer to avoid an unnecessary recompilation issue.

AppleWin port seems still using old Visual Studio 2017. If it
will switch to Visual Studio 2019 for better C++17 support,
Visual Studio 2019 needs CMake 3.14 or newer.
https://cmake.org/cmake/help/v3.14/release/3.14.html#generators

Happy WebKit 18th
birthday


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


[webkit-dev] Which WTF headers still should be in C++11?

2019-06-19 Thread Fujii Hironori
Hi,

wtf/CheckedArithmetic.h has been converted from C++14 to C++11.

Bug 195187 – Change CheckedArithmetic to not use std::enable_if_t.
https://bugs.webkit.org/show_bug.cgi?id=195187


Which WTF headers still should be in C++11?

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


Re: [webkit-dev] 'final' class specifier and 'final' method specifier

2018-12-20 Thread Fujii Hironori
On Fri, Dec 21, 2018 at 5:02 AM Konstantin Tokarev 
wrote:

> >
> > On Thu, Dec 20, 2018 at 7:42 AM  wrote:
> >> In that case, I'll point out that C++ Core Guidelines has a rule
> "Virtual functions should specify exactly one of virtual, override, or
> final".
> >> (
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
> >>
> >> Their tl;dr:
> >> "
> >> • virtual means exactly and only “this is a new virtual
> function.”
> >> • override means exactly and only “this is a non-final
> overrider.”
> >> • final means exactly and only “this is a final overrider.”
> >> "
> >>
> >> FWIW, they also have a rule "Use final sparingly" with the note that
> "Claims of performance improvements from final should be substantiated."
> >> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
> >
> > C.128 is a same rule with the current WebKit coding style guidelines.
> > But, I think C.128 makes sense with C.139.
> > C.139 is against to Bug 192844.
> > After Bug 192844 update, we will have a lot of 'final' classes, not
> sparignly.
>
> Do you have an idea how to automate this? Otherwise we'll never reach the
> state where all leaf classes are final, because doing it manually will
> take lots of
> time, and I see no way to enforce the rule in new code
>
>
 I don't have such intelligent plan. I don't like the divergence
between WebKit Code Style Guidelines and WebKit source code. I've
often got review feedbacks that I should modernize the code
around my change. I'm going to change them manually, and all
patches will be checked by reviewer's eyes. There is a previous
such effort.

Bug 159802 – Add final keyword to WebCore/svg classes
https://bugs.webkit.org/show_bug.cgi?id=159802


It seems that I shouldn't change the current 'final' method specifier rule
of WebKit.
Then, I think the sentences should be revised such like C.128.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] 'final' class specifier and 'final' method specifier

2018-12-19 Thread Fujii Hironori
Thank you very much for the feedbacks.

On Thu, Dec 20, 2018 at 4:52 AM Konstantin Tokarev 
wrote:

>
> 19.12.2018, 12:53, "Fujii Hironori" :
> > I'd like to change this because 'final' doesn't necessarily imply
> > 'override'. See the following stackoverflow:
> > https://stackoverflow.com/questions/29412412/does-final-imply-override
>
> It does imply override, unless it is used in a declaration of new virtual
> method
> (which has no practical meaning fwiw)
>

You are right. C++ allows using 'final' with 'virtual' without overriding.
Even though I don't know practical use-cases for it, C++ allows it because
'final' doesn't mean overriding.
And, this is the only reason 'final' doesn't necessarily imply override.
This is a kind of chicken egg problem. I don't know which is true:

1. C++ allows it because 'final' doesn't mean overriding.
2. 'final' doesn't necessarily imply override because C++ allows it

On Thu, Dec 20, 2018 at 6:28 AM Konstantin Tokarev 
wrote:

>
>
> 19.12.2018, 23:27, "Michael Catanzaro" :
> > On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev 
> > wrote:
> >>  Adding override to method which already has final specifier doesn't
> >>  affect anything,
> >>  because both final and override may ony be used on virtual methods
> >
> > FWIW I prefer override because it's much more clear what that keyword
> > is used for.
>
> If class itself has "final" specifier, "override" on methods works in the
> same way
> as "final", and I agree that it conveys intention more clear.


I think so, especially after I will update the code style guidelines in Bug
192844.

Bug 192844 – Update code style guidelines for using 'final' specifier for
all classes which has no derived classes
https://bugs.webkit.org/show_bug.cgi?id=192844




> However, Darin in [1]
> suggested that we use "final" aggressively to avoid accidentally losing
> compiler
> optimization (i.e. devirtualization of call)
>
> [1] https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html


I think this won't be a problem after all classes which has no derived
classes are capped with 'final'.


On Thu, Dec 20, 2018 at 7:42 AM  wrote:

> In that case, I'll point out that C++ Core Guidelines has a rule "Virtual
> functions should specify exactly one of virtual, override, or final".
> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
>
> Their tl;dr:
> "
> • virtual means exactly and only “this is a new virtual function.”
> • override means exactly and only “this is a non-final overrider.”
> • final means exactly and only “this is a final overrider.”
> "
>
> FWIW, they also have a rule "Use final sparingly" with the note that
> "Claims of performance improvements from final should be substantiated."
> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
>
>
C.128 is a same rule with the current WebKit coding style guidelines.
But, I think C.128 makes sense with C.139.
C.139 is against to Bug 192844.
After Bug 192844 update, we will have a lot of 'final' classes, not
sparignly.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] 'final' class specifier and 'final' method specifier

2018-12-19 Thread Fujii Hironori
Hi WebKit devs,

'final' keyword can be applied to both a class and a method
(non-static member function). I don't know correct terminology for
them. I call them 'final' class specifier and 'final' method
specifier.

I'm now going to update WebKit Code Style Guidelines for using 'final'
class specifier for all classes which has no derived classes in Bug
192844.
https://bugs.webkit.org/show_bug.cgi?id=192844

I believe this is not controversial. This is not a topic I'd like to
discuss today.

I'd like to discuss which 'override' or 'final' should be used for methods.

Currently, WebKit is using both inconsistently.
For example, CSSFontFaceSet class is marked 'final' and its methods are
marked 'final',
while CSSFontFaceSource class is marked 'final' and its methods are marked
'override'.
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSet.h?rev=239365#L93
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSource.h?rev=239365#L83


According to WebKit Code Style Guidelines, 'final' method specifier is
preferable to 'override' if possible. There is a previous discussion
thread.
https://webkit.org/code-style-guidelines/#override-methods
https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html

I'd like to change this because 'final' doesn't necessarily imply
'override'. See the following stackoverflow:
https://stackoverflow.com/questions/29412412/does-final-imply-override

IIUC, 'final' method specifier can be useful for such like the following
case:

class B {
public:
  virtual foo();
  virtual bar();
};
class B1 : public B {
  foo() final;
};
class D final : B1 {
  bar() override;
};


The 'final' method specifier indicates D can't override the method foo.
Thus, using 'final' method specifier implies other virtual functions
can be overridden. I'm not sure my understanding right. Please correct me.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-18 Thread Fujii Hironori
On Wed, Dec 19, 2018 at 6:41 AM Konstantin Tokarev 
wrote:

>
> I agree that "atomic" part of AtomicString is kinda misleading, however
> wiki
> explains it all
>
> https://trac.webkit.org/wiki/EfficientStrings#AtomicStringVSString
>
> BTW, /me personally didn't know what "interned string" is until today :)
>

The return value of RegisterClass Win32 API is ATOM.
And, Lisp has the similar concepts of intern and atom.
I've never thought AtomicString is a confusing name until I see you
comments today.
It is a intrinsic name for me as a Win32 and Lisp programmer.

https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-addatoma
https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-registerclassa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-18 Thread Fujii Hironori
On Tue, Dec 18, 2018 at 10:21 PM Fujii Hironori 
wrote:

>
> On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa 
> wrote:
>
>> Also, as Geoff has already pointed out, the behavior of STL doesn't
>> prevent us from writing our own template library to always have a very well
>> specified & good state after std::move'ed & its value was move-constructed.
>>
>
> Do you mean only WTF classes should guarantee the valid empty state after
> moved-out?
> Should we use std::exchange and std::move properly for other classes in
> WebKit?
>
>

I guess the answer is all classes in WebKit which are moved by WTFMove.
I'm wondering how much runtime cost it will take to restore valid empty
state of all moved-out values.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-18 Thread Fujii Hironori
On Tue, Dec 18, 2018 at 12:25 PM Ryosuke Niwa 
wrote:

> Also, as Geoff has already pointed out, the behavior of STL doesn't
> prevent us from writing our own template library to always have a very well
> specified & good state after std::move'ed & its value was move-constructed.
>

Do you mean only WTF classes should guarantee the valid empty state after
moved-out?
Should we use std::exchange and std::move properly for other classes in
WebKit?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Fujii Hironori
On Tue, Dec 18, 2018 at 11:16 AM Maciej Stachowiak  wrote:

>
>  Among other things, this allows for a “did anything actually get left
> here” check after the function that may or may not move a value. Seems like
> an upgrade.
>
>
Don't recommend such checks. It is simply use-after-move. The expression
WTFMove(x) means marking x as disposable.

On Tue, Dec 18, 2018 at 8:55 AM Alex Christensen 
wrote:

>  I think we should do something to track and prevent the use of moved-from
> values instead of introducing our own std::optional replacement.
>

Do you have a idea?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Fujii Hironori
On Mon, Dec 17, 2018 at 4:55 PM Maciej Stachowiak  wrote:

>
> Maybe there is an option I am missing? Out of these, I think (2) is likely
> the best, on the whole.
>
>
Reasonable.
But, some classes need to be modification for that.
For example, WTF::URL is using default move constructor.
I think we should add the move constructor to restore the valid null value
after move.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-16 Thread Fujii Hironori
I've changed my mind.

It is ensured std::vector move constructor makes moved value empty.

> After the move, other is guaranteed to be empty().

https://en.cppreference.com/w/cpp/container/vector/vector

Unfortunately, WTF::Vector move constructor just swaps values.
I think this swapping is not a specified behavior WebKit developers can
rely on.

https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Vector.h?rev=238031#L950

I think WTF::Vector also should ensure moved values become empty.

Looking through the grepping "WTFMove(m_”result, some of them are valid
because:
1. It is in dtor. 'this' object is about to be destructed.
2. It is in ref-qualified method. 'this' object is about to be destructed.
3. It is Ref<>. As well as std::shared_ptr, it should be defined to become
null after moved.

Common misuse cases are moving Vector like following code.

void SVGDocumentExtensions::rebuildElements()
> {
> Vector shadowRebuildElements = WTFMove(m_rebuildElements);


I thought std::exchange should be used for these purpose.
But, if WTF::Vector move constructor is changed, this code would be valid.
m_rebuildElements would become empty as expected, not accidentally.

If above code would be valid, there would be no reason to object we have
custom Optional class which guarantees moved values become empty.


BWT, FWIW,
clang-tidy has use-after-move checker.

clang-tidy - bugprone-use-after-move — Extra Clang Tools 8 documentation
http://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html


As expected, it doesn't support member variables.

The check currently only considers calls of std::move on local variables or
> function parameters. It does not check moves of member variables or global
> variables.


It seems UBSan doesn't check use-after-move.

UndefinedBehaviorSanitizer — Clang 8 documentation
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#ubsan-checks
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-16 Thread Fujii Hironori
I don't like the proposal because it encourages misuse of move.
We can use move only for values about to be destroyed.

I like Dan's suggestion. We should use std::exchange or std::optional::swap
for the cases.
Or, what about adding a new method WTF::Optional::release() for the case?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-14 Thread Fujii Hironori
On Sat, Dec 15, 2018 at 8:46 AM Chris Dumez  wrote:

>
>
> This is the latest one: https://trac.webkit.org/changeset/239228/webkit
>

This expression WTFMove(*m_pendingWebsitePolicies) doesn't move
std::optional, but moves the content of the
std::optional, WebsitePoliciesData. I think your proposal doesn't work for
this code.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

2018-12-13 Thread Fujii Hironori
Hi everyone,


I would like to announce that Don Olmstead (dolmstead on #webkit) and

Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked

on WinCairo port and PlayStation port, and Ross worked on Web

Inspector Layers Tab, too.


Please join me in congratulating Don and Ross, and send them patches

to review.


Don and Ross, congratulations. 


- Fujii Hironori, Sony Interactive Entertainment Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebCorePrefix.h vs. config.h

2018-12-11 Thread Fujii Hironori
On Wed, Dec 12, 2018 at 7:07 AM Darin Adler  wrote:

> > On Dec 9, 2018, at 10:34 PM, Fujii Hironori 
> wrote:
> >
> > MSVC has /FI option.
> >
> >   /FI (Name Forced Include File) | Microsoft Docs
> >
> https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017
> >
> > Unfortunately, it seems that MSVC's precompiled header needs to be
> included explicitly.
> >
> >   /Yu (Use Precompiled Header File) | Microsoft Docs
> >
> https://docs.microsoft.com/en-us/cpp/build/reference/yu-use-precompiled-header-file?view=vs-2017
>
> So this seems like the main potential obstacle. We can force an include of
> a prefix header, or precompile a header, but not both, with the Microsoft
> compiler.
>

It was just my misunderstanding. WebKit Windows ports are already using
both /Yu and /FI.
https://trac.webkit.org/browser/webkit/trunk/Source/cmake/WebKitMacros.cmake?rev=229282#L100

 It seems that WebKit can stop including config.h in all source fils.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebCorePrefix.h vs. config.h

2018-12-09 Thread Fujii Hironori
On Sun, Dec 9, 2018 at 8:22 AM Darin Adler  wrote:

> Best would be to eliminate “config.h”: Change “config.h” into an empty
> file first, then remove all “config.h” includes, and then remove the file.
> But to do that, we need to make sure every build system for WebKit supports
> prefix headers. I don’t know how close to that we are. Maybe close? How can
> we quickly find out?


 GCC and Clang support '-include ' option.

  https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

  https://clang.llvm.org/docs/ClangCommandLineReference.html


GTK and WPE ports are using it only in WK2 since r163032.

  https://trac.webkit.org/changeset/163032


MSVC has /FI option.

  /FI (Name Forced Include File) | Microsoft Docs

https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017


Unfortunately, it seems that MSVC's precompiled header needs to be included
explicitly.

  /Yu (Use Precompiled Header File) | Microsoft Docs

https://docs.microsoft.com/en-us/cpp/build/reference/yu-use-precompiled-header-file?view=vs-2017

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


Re: [webkit-dev] Lots of spam on Bugzilla

2018-12-04 Thread Fujii Hironori
On Wed, Dec 5, 2018 at 6:30 AM Alexey Proskuryakov  wrote:

>
> What I would want to know is what lures spammers to bugzilla. Perhaps we
> can find a way to decrease bugs.webkit.org page rank or whatever makes it
> a valuable target.
>
>
What about adding nofollow. Mozilla bugzilla is using nofollow, for example,

 

Here is the Goole document about nofollow:

  Use rel="nofollow" for specific links - Search Console Help
  https://support.google.com/webmasters/answer/96569?hl=en

LLVM bugzilla  says:

> New user self-registration is disabled due to spam.

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


Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-19 Thread Fujii Hironori
On Sat, Nov 17, 2018 at 3:45 AM Ryosuke Niwa  wrote:

> I think the right macro to use here would have HAVE(ACCESSIBILITY). It
> never makes sense to compile out accessibility support if you have the
> support in a given platform/port. The question is really whether a given
> port / platform has the support for accessibility or not.
>
>
Thank you for the feedback.
Let's keep HAVE_ACCESSIBILITY macro.

Can I remove ENABLE_ACCESSIBILITY CMake variable?
It is used only in WebKitTestRunner.


https://github.com/WebKit/webkit/blob/dea6e0141a5df7b678221d4a474b5846176a913d/Tools/WebKitTestRunner/CMakeLists.txt#L76

Do you want to keep this condition by renaming it to HAVE_ACCESSIBILITY
CMake variable?

> if (HAVE_ACCESSIBILITY)

We can not keep this code by using platform variable, for example
WTF_PLATFORM_WIN_CAIRO, because no port is using the code.

> if (WTF_PLATFORM_WIN_CAIRO)

Or, keep it by doing following?

> if (FALSE)

Bug 191831 – [CMake] Remove ENABLE_ACCESSIBILITY CMake variable
https://bugs.webkit.org/show_bug.cgi?id=191831
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Fujii Hironori
On Thu, Nov 15, 2018 at 12:05 PM Timothy Hatcher  wrote:

> It wasn’t added for Tesla. But they did build with it disabled at the time
> I lasted worked on it. It was a frequent pain point to keep the build
> working when AX changes happened.
>
>

For the record, HAVE_ACCESSIBILITY has been introduced in the followoing
commits.

https://trac.webkit.org/changeset/31986
https://trac.webkit.org/changeset/32042
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Fujii Hironori
On Thu, Nov 15, 2018 at 10:29 AM Ryosuke Niwa  wrote:

> I think it was added for Telsa's private port. Probably not worth
> maintaining the flag if the maintenance cost is high but is it?
>

 No, it isn't high. It is no problem to keep the code.

CMake defines the similar name macro ENABLE_ACCESSIBILITY=0 in generated
cmakeconfig.h.


https://trac.webkit.org/browser/webkit/trunk/Source/cmake/WebKitFeatures.cmake#L88

This confuses me. I want to fix.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Fujii Hironori
Hi webkit-dev,

It seems that all port defines HAVE_ACCESSIBILITY=1. Can I remove all code
for !HAVE(ACCESSIBILITY)?

https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Platform.h?rev=237992#L648

  #if PLATFORM(COCOA) || PLATFORM(WIN) || PLATFORM(GTK) || PLATFORM(WPE)
  #define HAVE_ACCESSIBILITY 1
  #endif

Bug 21802 – Rename HAVE_ACCESSIBILITY to ENABLE_ACCESSIBILITY
https://bugs.webkit.org/show_bug.cgi?id=21802

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


Re: [webkit-dev] Rename wtf/unicode/UTF8.h

2018-10-31 Thread Fujii Hironori
Thank you for the feedback, Konstantin and Darin.

On Thu, Nov 1, 2018 at 1:52 AM Darin Adler  wrote:

>
> With a few seconds thought I am thinking that maybe UTF8Conversion.h or
> UTF8Transcoding.h are possible better ideas for new names. Neither is
> completely accurate. If we were going to add the word “helpers” than I
> would say UTF8Helpers.h, but I really don’t like those kinds of word in
> header names (“utilities”, “helpers”, “functions”, “classes”).
>

Sounds good. I take UTF8Conversion.h.


> A separate issue once we rename: the header is also pretty old and crufty.
> Eventually we might want to remove or refine the functions in here. Not
> sure how widely they are used.
>

 There are 8 functions in the header.

Following 2 functions are used only in
JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp.

* UTF8SequenceLength
* decodeUTF8Sequence

Following 3 functions are used only in WTF/wtf/text/AtomicStringImpl.cpp

* calculateStringHashAndLengthFromUTF8MaskingTop8Bits
* equalUTF16WithUTF8
* equalLatin1WithUTF8

Following 3 functions are widely used

* convertUTF8ToUTF16
* convertLatin1ToUTF8
* convertUTF16ToUTF8

Any suggestions are welcome to improve.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Rename wtf/unicode/UTF8.h

2018-10-31 Thread Fujii Hironori
Oh no. I didn't know that. Thank you for letting me know.

Then, how about ?
There is  which has '-' in the name.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Rename wtf/unicode/UTF8.h

2018-10-30 Thread Fujii Hironori
wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like
to rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h.
Any suggestion?

Here is ICU's #include "unicode/utf8.h" which happens to include
wtf/unicode/UTF8.h
https://github.com/unicode-org/icu/blob/master/icu4c/source/common/unicode/utf.h#L217

Here is MSVC quoted form #include behavior documented.
https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

Bug 189693 – [Win][Clang] warning: #include resolved using non-portable
Microsoft search rules as: ..\..\Source\WTF\wtf/unicode/utf8.h
https://bugs.webkit.org/show_bug.cgi?id=189693

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


Re: [webkit-dev] WinCairo EWS bot broken?

2018-09-30 Thread Fujii Hironori
I apologize for the inconvenience.
I'm going to look into it in the following bug ticket.
https://bugs.webkit.org/show_bug.cgi?id=187725

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


Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

2018-07-15 Thread Fujii Hironori
Thank you very much! I'm honored to become a WebKit reviewer.

Fujii

2018年7月15日(日) 2:30 Michael Catanzaro :

> Hi,
>
> Fujii Hironori is now a WebKit reviewer. He has expertise in Windows
> support, WebKitGTK+, and WebCore bugs. Please congratulate him and send
> him patches to review!
>
> Michael
>
> ___
> 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] Meltdown and Spectre attacks

2018-01-11 Thread Fujii Hironori
Hi Filip,

Thank you for writing the nice article.
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

I have a question. What's the reason why the patch (5) isn't shipped yet?

On Sat, Jan 6, 2018 at 4:37 AM, Filip Pizlo  wrote:
> Here is what else is in trunk:
>
> - index masking
> - pointer poisoning
>
> I’m going to write up what our thoughts are shortly. :-)  For now feel free
> to browse the code with those two hints.
>
> -Filip
>
>
> On Jan 5, 2018, at 8:31 AM, Konstantin Tokarev  wrote:
>
>
>
> Hi,
>
> Here's a collection of blog posts from other major browser vendors
> regarding the Meltdown and Spectre attacks:
>
> https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
>
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
>
> Notably, Edge and Firefox are reducing the resolution of
> performance.now(), and all three are disabling SharedArrayBuffer.
>
> This is just a heads-up.
>
>
> Seems like both mitigations are already present in trunk
>
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> --
> Regards,
> Konstantin
> ___
> 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] Linking against MultiThreadedDLL instead of MultiThreaded on Windows (wincairo)

2017-05-19 Thread Fujii Hironori
On Fri, May 19, 2017 at 5:24 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> On 19 May 2017 at 16:16, Fujii Hironori <fujii.hiron...@gmail.com> 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 <https://bugs.webkit.org/show_bug.cgi?id=157067#c9>.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-23 Thread Fujii Hironori
On Fri, Sep 23, 2016 at 5:14 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>
>
> 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com>:
>> Requiring CMake 3.0 would not cause us a problem.
>
> Looks like anyone is fine with updating CMake to 3.0, however Fujii Hironori 
> is asking about CMake 3.2, and AFAIU updating to 3.0 won't help for his patch.
> .

That's right.
Debian 9 will be released in 2017. <https://wiki.debian.org/DebianStretch>
One year after Debian 9 is released, CMake 3.5 will the minimum
version to be supported, which is included in Ubuntu 16.4.
I can not wait for that.
I will take the approach of switching by CMAKE_VERSION like the following code.

> if (${CMAKE_VERSION} VERSION_LESS 3.2)

Thank you.

---
hironori.fu...@sony.com  Sony Interactive Entertainment
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-21 Thread Fujii Hironori
On Wed, Sep 21, 2016 at 12:39 AM, Michael Catanzaro
<mcatanz...@igalia.com> wrote:
> On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote:
>
> WebKitGTK+ intends to continue supporting 2.8.12 until April, when we
> drop support for Ubuntu 14.04. So the new features you want to use
> should be used conditionally on the CMake version being high enough,
> without bumping the minimum requirement.

Ubuntu 14.04 has GCC 4.8 and build fails with a following error message.

> CMake Error at Source/cmake/OptionsGTK.cmake:12 (message):
>   GCC 4.9.0 is required to build WebKitGTK+, use a newer GCC version or clang

Do you think WebKit should support GCC 4.8?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-20 Thread Fujii Hironori
Oops. I replied personally. I repost my and his messages again.

On Tue, 20 Sep 2016 19:34:36 +0900,
Fujii Hironori wrote:
>
> On Tue, Sep 20, 2016 at 2:58 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> >
> > Supporting 2.8.12 allows building on more older/LTS systems using
> > cmake installed from repositories. For example, CentOS 6 and Ubuntu
> > 14.04 ship cmake 2.8.12.2, and Debian stable ships 3.0.2
>
> I want to use USES_TERMINAL switch of add_custom_command
> introduced in CMake v3.2.
>   <https://cmake.org/cmake/help/v3.2/command/add_custom_command.html>
> But, this is not necessary.
> I can switch with CMAKE_VERSION for old version.
>   <https://cmake.org/cmake/help/v3.2/variable/CMAKE_VERSION.html>
>
> WebKit uses new technologies C++14 and CMake Ninja generator.
> Is it possible to build WebKit on such old Linux distribution?


On Tue, 20 Sep 2016 20:18:46 +0900,
Konstantin Tokarev wrote:
>
> Sure, RedHat provides gcc updates, and it's also possible to use clang from 
> official binaries.
>
> That said, upgrading CMake can bring other benefits, i.e. it will be possible 
> to start build system refactor to use more modern practices. It should also 
> be possible to add cmake to jhbuild so required version could be 
> automatically built from sources


On Tue, 20 Sep 2016 20:34:39 +0900,
Konstantin Tokarev wrote:
> As for Debian, it ships gcc 4.9 as default compiler


On Tue, 20 Sep 2016 20:31:55 +0900,
Konstantin Tokarev wrote:
>
> > I want to use USES_TERMINAL switch of add_custom_command
> > introduced in CMake v3.2.
> >   <https://cmake.org/cmake/help/v3.2/command/add_custom_command.html>
>
> Do I understand correctly that you are not going to use terminal input, but 
> just move target to another ("console") pool so other targets are not built 
> in paralell with it?
>
> It would be great if cmake allowed more fine-grained control over ninja 
> pools, I was considering adding perl script that modifies generated 
> build.ninja

USES_TERMINAL has two effects which I want:

1) isolated Ninja pool to inhibit background parallel build
2) terminal output during executing a command
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-20 Thread Fujii Hironori
I'm interested in bumping cmake_minimum_required for
.
Which version of CMake is minimum version to be supported?

---
hironori.fu...@sony.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev