Hi, > I think the cmake.mk-link approach would be a good idea and given > previous discussions the plan is afaik to pull in Ninja first and > once that's confirmed working via CMake add support for Meson.
fine with me. > Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan > it seems like a good idea to stick with 3.7? No opinion. > As for OpenWrt, there are already files with hard dependency of > python3 dating back to 2015 doing a quick grep of the source tree. > > https://github.com/openwrt/openwrt/blob/master/scripts/dl_cleanup.py > https://github.com/openwrt/openwrt/blob/master/scripts/flashing/eva_ramboot.py Both files are supplemental scripts not used as part of the actual build process. > There are also upstream projects like wireless-db that doesn't > compile/build cleanly with vanilla 2.7 > https://github.com/openwrt/openwrt/pull/1521 On the other end of the spectrum there is SCons (include/scons.mk) which apparently explicitly does not support Python 3 [1]. Having to depend on two Python versions is not ideal. Maybe it is worth sacrificing scons support for meson, depending on the number of users. ~ Jo 1: https://bitbucket.org/scons/scons/wiki/FrequentlyAskedQuestions#markdown-header-am-i-restricted-to-using-python-24-code-in-my-sconscript-files
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel