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.
This is a meta bug for the goal.
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.
(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?
(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.
(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?
> Also can EWS catch those internal build break? No.
(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.
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.
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.