206901 2020-01-28 12:06:03 -0800 [webkitperl] Clean up webkitdirs.pm 2021-10-17 12:43:46 -0700 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=231868 P2 Normal --- 231869 1 basuke webkit-unassigned ap basuke jbedard krollin stephan.szabo oldest_to_newest 1612102 0 basuke 2020-01-28 12:06:03 -0800 If we are moving to python toolchain, no need to do that. But for many years, things have been untouched and it seems same in the near future. Let's start cleaning up the messy webkitdir.pm and modularlize them into webkitperl directory. 1612107 1 basuke 2020-01-28 12:27:26 -0800 This is a meta bug for the goal. 1612115 2 ap 2020-01-28 12:42:21 -0800 This is going to be tough because of how webkitdirs.pm is used by into Apple internal scripts. But definitely a lot to improve here. 1614079 3 basuke 2020-02-03 12:15:02 -0800 (In reply to Alexey Proskuryakov from comment #2) > This is going to be tough because of how webkitdirs.pm is used by into Apple > internal scripts. But definitely a lot to improve here. Are there a lot of changes in Apple internal branch? 1614184 4 jbedard 2020-02-03 14:46:35 -0800 (In reply to Basuke Suzuki from comment #3) > (In reply to Alexey Proskuryakov from comment #2) > > This is going to be tough because of how webkitdirs.pm is used by into Apple > > internal scripts. But definitely a lot to improve here. > > Are there a lot of changes in Apple internal branch? It not that there are possible conflicts, it's that there is code that might look dead in WebKit that's actually used by Apple internal scripts, or code that is used by Apple internal scripts in ways that the callee is not expecting. 1615733 5 basuke 2020-02-06 12:18:24 -0800 (In reply to Jonathan Bedard from comment #4) > (In reply to Basuke Suzuki from comment #3) > > (In reply to Alexey Proskuryakov from comment #2) > > > This is going to be tough because of how webkitdirs.pm is used by into Apple > > > internal scripts. But definitely a lot to improve here. > > > > Are there a lot of changes in Apple internal branch? > > It not that there are possible conflicts, it's that there is code that might > look dead in WebKit that's actually used by Apple internal scripts, or code > that is used by Apple internal scripts in ways that the callee is not > expecting. Can Apple add unit test for those? Oh, wait. There's no unittest for webkitdirs.pm lol So deleting unused function or changing interface of existing one will be dangerous, isn't it? Also can EWS catch those internal build break? 1615776 6 ap 2020-02-06 13:47:46 -0800 > Also can EWS catch those internal build break? No. 1616278 7 basuke 2020-02-07 11:37:38 -0800 (In reply to Alexey Proskuryakov from comment #6) > > Also can EWS catch those internal build break? > > No. That's so scary. Anyway, first target may be for CMake build related one. 1800949 8 basuke 2021-10-05 22:25:58 -0700 Goal: - Modernize the codebase to 2021 perl syntax conventions - Modularize by features. - Modularize by platform. - Stop using ad-hoc command line arguments. Document them well. (detect misspelled option) - Passing cmake arguments easily. (i.e. arguments after "--" will be passed to cmake. Tools/Scripts/build-webkit --wincairo -- -DUSE_SYSTEM_MALLOC=Off) Currently the last one is already implemented, but it conflicts with the other goal, "stop using ad-hoc command" because there's no clear separation to options to cmake args. Using "--" is a new thing and a good sign to introduce new features, I think. 1800956 9 basuke 2021-10-05 22:49:29 -0700 Something like this: 1. Tools/Scripts/build-webkit --unknown-option Run as same as current. Maybe display warnings in the future 2. Tools/Scripts/build-webkit -DSOME_CMAKE_VAR=Off Run as same as current. Will be added to cmake args. Maybe warnings in the future. 3. Tools/Scripts/build-webkit --unknown-option -- Error. Unknown option "--unknown-option" 3. Tools/Scripts/build-webkit --wincairo -- -DUSE_SYSTEM_MALLOC=Off Option --wincairo is used and "-DUSE_SYSTEM_MALLOC=Off" will be passed to cmake on top of the generated arguments in the script.