After the refactoring, both lupdate and lupdate-pro could handle .pro files, which creates ambiguity about which tool to use. The original reasoning behind separating lupdate and lupdate-pro was to make lupdate build system agnostic. Before separation, lupdate used to favor qmake over cmake, by directly employing a qmake parser and receiving .pro file as input. To prevent lupdate to favor any build system (qmake or cmake), the idea was to change lupdate to either directly get the sources, or get a .json file describing the project. The json file could be generated by either qmake or cmake. Then lupdate-pro was added to specifically handle qmake projects (as in lupdate -pro project.pro) This change adds deprecation warnings when lupdate is used to process .pro or .pri files. Also since most of the testcases of lupdate used .pro files, in tst_lupdate lupdate-pro is used if the test case contains a .pro file. Additionally, to support tr_function_alias testcase, which now uses lupdate-pro, the handleTrFunctionAliases() logic is extracted from lupdate to LinguistCore to be reused in lupdate-pro. Pick-to: 6.11 Change-Id: Id0c20484e532f80ec0a25cf6902fd32a54a39ea7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>